Agent identity issuing method and device, equipment and medium

Abstract

This invention provides a method, apparatus, device, and medium for issuing agent identities, relating to the field of agent technology. The method includes: generating a one-time issuance challenge in response to an issuance challenge request sent by a registrant client; issuing an anchor access credential to the registrant client in response to a device verification packet returned by the registrant client based on the one-time issuance challenge, provided the device verification packet passes verification; and generating an idempotent key corresponding to the agent registration request in response to an agent registration request returned by the registrant client based on the anchor access credential, to determine the identity registration result corresponding to the agent registration request based on the current registration state corresponding to the idempotent key. This invention effectively alleviates problems existing in the prior art, such as the agent identity private key being copied and migrated by the software side, the inability to bind the hardware key holding fact to the current identity issuance request in real time, and the repeated issuance of multiple identities by the same public key in concurrent / retry scenarios.

Description

Technical Field

[0001] This invention relates to the field of intelligent agent technology, and in particular to an intelligent agent identity signing method, apparatus, device and medium. Background Technology

[0002] Existing identity signing schemes for intelligent agents, automated programs, or software services typically rely on platform accounts, API keys (Application Programming Interface keys), software public and private keys, digital certificates, DIDs (Decentralized Identifiers), or verifiable credentials to identify the entity. During platform registration, the platform receives the public key, account information, or device information submitted by the applicant, verifies it, and issues an identity number, token, or credential. External systems then determine the validity of the intelligent agent based on the signature, validity period, status list, or query interface.

[0003] Other solutions incorporate hardware authentication capabilities such as U-Key (Universal Key Token), TPM (Trusted Platform Module), HSM (Hardware Security Module), eSIM (embedded Subscriber Identity Module), security chips, smart cards, trusted gateways, or terminal security modules. These solutions are typically used for account login, device access control, remote authentication, or device certificate verification, demonstrating that a device or security module has participated in authentication.

[0004] Other digital identity status management solutions manage credential validity through revocation lists, status bitmaps, status inventories, and on-chain or off-chain registries. These solutions focus on credential format, issuer credibility, and revocation status, and typically do not require the identity private key to be generated or held in hardware, nor do they require hardware key holding proof to be bound to the identity's birth transaction.

[0005] The above-mentioned scheme has at least the following shortcomings in the intelligent agent identity issuance scenario: the intelligent agent's private key can be copied and migrated by the software side, the hardware key holding fact cannot be bound to the current identity issuance request in real time, and the same public key can be repeatedly issued for multiple identities in concurrent / retry scenarios. Summary of the Invention

[0006] In view of this, the purpose of the present invention is to provide a method, apparatus, device and medium for issuing agent identities, which can effectively alleviate the problems existing in the prior art, such as the private key of an agent identity being copied and migrated by the software side, the fact that the hardware holds the key not being able to be bound to the current identity issuance request in real time, and the same public key being repeatedly issued to multiple identities in concurrent / retry scenarios.

[0007] In a first aspect, the present invention provides a method for issuing an identity for an intelligent agent, the method being applied to an identity issuance system, the method comprising: In response to the issuance challenge request sent by the registrant's client, a one-time issuance challenge is generated; In response to the device proof packet returned by the registrant client based on the one-time issuance challenge, if the device proof packet is verified, the anchor access credential is issued to the registrant client. The device proof packet is formed by the registrant client signing the one-time issuance challenge using the private key of the intelligent agent identity configured to be non-exportable in the hardware anchor. In response to the agent registration request returned by the registrant client based on the anchor access credential, an idempotent key corresponding to the agent registration request is generated to determine the identity registration result corresponding to the agent registration request based on the current registration status corresponding to the idempotent key.

[0008] In one implementation, the identity issuance system includes an issuance challenge module; in response to an issuance challenge request sent by the registrant client, generating a one-time issuance challenge includes: The issuance challenge module receives issuance challenge requests sent by the registrant's client and generates a one-time issuance challenge for each request. The one-time issuance challenge is used to bind the registration session corresponding to the issuance challenge request, the specified hardware anchor, and the public key to be issued to the same time window defined by the issuance time and the expiration time.

[0009] In one implementation, the identity issuance system includes a unified anchor verification layer and an anchor access credential service; in response to a device verification packet returned by the registrant client based on a one-time issuance challenge, and upon successful verification of the device verification packet, an anchor access credential is issued to the registrant client, including: Through the unified anchor verification layer, the device verification package returned by the registrant client based on the one-time issuance challenge is received, and the anchor verification process matching the form type of the hardware anchor is invoked to verify the device verification package. If the device verification package fails to pass verification, a verification failure instruction is sent to the anchor access credential service through the unified anchor verification layer, and the anchor access credential service refuses to issue the anchor access credential. If the device verification package passes verification, a verification success command is sent to the anchor access credential service through the unified anchor verification layer. The anchor access credential service then issues an anchor access credential to the registrant client based on the device verification package.

[0010] In one implementation, the identity issuance system further includes an identity issuance center; in response to a smart agent registration request returned by the registrant client based on the anchor access credential, it generates an idempotent key corresponding to the smart agent registration request, and determines the identity registration result corresponding to the smart agent registration request based on the current registration state corresponding to the idempotent key, including: Perform the following operations through the identity issuance center: Receive the agent registration request returned by the registrant client based on the anchor access credential; Extract the registration entity identifier, namespace, request number, and public key of the smart agent to be bound from the smart agent registration request to generate the idempotent key corresponding to the smart agent registration request; Query the current registration status corresponding to the idempotent key in the registration attempt state machine; If there is no current registration state corresponding to the idempotent key in the registration attempt state machine, then if the agent registration request is verified, an identity issuance transaction is performed. The identity issuance transaction includes at least allocating an agent identity number and constructing a public identity statement to obtain the identity registration result.

[0011] In one implementation, the method further includes: If the current registration status corresponding to the idempotent key is "submitted successfully", then read the identity master file corresponding to the idempotent key and use the agent identity number and public identity declaration recorded in the identity master file as the identity registration result.

[0012] In one implementation, the method further includes: If the current registration status corresponding to the idempotent key is a retryable failure status, then if the current number of retries has not reached the preset threshold, the identity issuance transaction will be retried and the number of retries will be updated; if the current number of retries has reached the preset threshold, then the current registration status corresponding to the idempotent key will be updated to the final failure status.

[0013] In one implementation, the method further includes: If the current registration status corresponding to the idempotent key is a final failure status, then an error message is returned to the registrant client.

[0014] Secondly, the present invention also provides an intelligent agent identity issuance system, comprising: The issuance challenge module is used to respond to the issuance challenge request sent by the registrant's client and generate a one-time issuance challenge; The unified anchor verification layer and anchor access credential service are used to respond to the device proof packet returned by the registrant client based on the one-time issuance challenge. If the device proof packet is verified, the anchor access credential is issued to the registrant client. The device proof packet is formed by the registrant client signing the one-time issuance challenge using the private key of the smart agent identity configured to be non-exportable in the hardware anchor. The identity issuance center is used to respond to the agent registration request returned by the registrant client based on the anchor access credential, generate the idempotent key corresponding to the agent registration request, and determine the identity registration result corresponding to the agent registration request based on the current registration status corresponding to the idempotent key.

[0015] Thirdly, the present invention also provides an electronic device including a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement any of the methods provided in the first aspect.

[0016] Fourthly, the present invention also provides a computer-readable storage medium storing computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement any of the methods provided in the first aspect.

[0017] This invention provides a method, apparatus, device, and medium for issuing agent identities. First, in response to an issuance challenge request sent by a registrant client, a one-time issuance challenge is generated. Then, in response to a device verification packet returned by the registrant client based on the one-time issuance challenge, if the device verification packet is verified, an anchor access credential is issued to the registrant client. The device verification packet is formed by the registrant client signing the one-time issuance challenge using an agent identity private key configured as non-exportable within the hardware anchor. Finally, in response to an agent registration request returned by the registrant client based on the anchor access credential, an idempotent key corresponding to the agent registration request is generated. The identity registration result corresponding to the agent registration request is determined based on the current registration state corresponding to the idempotent key. This invention effectively alleviates problems existing in the prior art, such as the agent identity private key being copied and migrated by the software side, the inability to bind the hardware key holding fact to the current identity issuance request in real time, and the repeated issuance of multiple identities with the same public key in concurrent / retry scenarios.

[0018] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained through the structures particularly pointed out in the description and the drawings.

[0019] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

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

[0021] Figure 1 A flowchart illustrating an intelligent agent identity issuance method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of an intelligent agent identity issuance chain that does not require the private key to be produced in the hardware, provided as an embodiment of the present invention. Figure 3 A flowchart illustrating a one-time issuance challenge and hardware key holding proof is provided for an embodiment of the present invention. Figure 4 This invention provides a registration attempt state machine, idempotent key, and public key unique index diagram. Figure 5 A visibility boundary graph for binding public credentials to internal devices is provided as an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of an intelligent agent identity issuance system provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0023] Currently, existing solutions have at least the following shortcomings in the intelligent agent identity issuance scenario.

[0024] First, when the software generates, imports, or saves the private key, the private key may be copied, exported, or migrated. After an attacker obtains the private key or complete identity credentials, they can run the same agent identity on another device, making it difficult for the platform to prove that the identity is still controlled by the original device.

[0025] Second, ordinary device certificates or hardware logins can only prove that a device has participated in authentication, but cannot fully prove that the agent_pubkey in this agent identity issuance request does indeed correspond to a non-exportable private key in the hardware, nor can they prove that the hardware private key participated in the identity birth process in real time.

[0026] Third, if device verification, real-name verification, registration application, identity issuance, and status bit allocation belong to different systems, it is easy to encounter situations where the device has been verified but the identity master file is not bound to the fact, or the identity has been issued but the specific device verification and key slot cannot be traced.

[0027] Fourth, in scenarios involving concurrent registration, network retries, or call timeouts, the same registration request, the same smart agent public key, or the same device proof may be processed repeatedly, resulting in multiple identity numbers being bound to the same public key or the same hardware anchor.

[0028] Fifth, directly writing ICCID (Integrated Circuit Card Identifier), EID (embedded SIM Identifier), device serial number, real-name entity, certificate number, or original device proof into the public identity statement will cause privacy leaks and cross-scenario association risks.

[0029] Therefore, a technical solution specifically for the birth of intelligent agent identity is needed to prove that the private key does not leave the hardware boundary before issuance, and to put the hardware key holding certificate, anchor access certificate, registration application, idempotent issuance and device binding fact into the same auditable transaction during issuance, and to expose only the necessary verification fields in the public certificate.

[0030] Based on this, the present invention provides a method, apparatus, device and medium for issuing intelligent agent identity, which can effectively alleviate the above-mentioned problems existing in the prior art.

[0031] To facilitate understanding of this embodiment, a method for issuing an identity for an intelligent agent, disclosed in this embodiment of the invention, will first be described in detail. This method is applied to an identity issuance system. See [link to relevant documentation]. Figure 1 The diagram shows a flowchart of a method for issuing an identity for an intelligent agent. This method mainly includes the following steps S102 to S106: Step S102: In response to the issuance challenge request sent by the registrant client, a one-time issuance challenge is generated.

[0032] The registrant client refers to the software program or service module that initiates the identity issuance process on behalf of the intelligent agent registration entity (such as an enterprise, developer, or device owner), and runs on a general-purpose computing device. The issuance challenge request is the initial network request initiated by the registrant client to the identity issuance system to trigger the generation of a one-time challenge. Its payload includes at least the registration entity identifier, the desired hardware anchor type, and the namespace. The one-time issuance challenge is a cryptographic challenge data structure generated by the issuance challenge module in the identity issuance system, valid only within the current registration session and not reusable.

[0033] In one implementation, the issuance challenge module receives an issuance challenge request sent by the registrant's client and generates a one-time issuance challenge in response to the issuance challenge request.

[0034] Step S104: In response to the device verification packet returned by the registrant client based on the one-time issuance challenge, if the device verification packet is verified successfully, issue an anchor access credential to the registrant client.

[0035] The device proof packet is formed by the registrant client signing the one-time issuance challenge using a private key for the agent's identity configured as non-exportable within the hardware anchor. The hardware anchor can be AI-eSIM (Artificial Intelligence-enhanced embedded Subscriber Identity Module), eUICC (embedded Universal Integrated Circuit Card), iSIM (integrated Subscriber Identity Module), U-Key, TPM, HSM, smart card, security chip, trusted gateway, or terminal security module. The anchor access credential is an intermediate credential used to carry hardware key proof; it does not constitute a public identity statement and does not contain original device plaintext such as ICCID, EID, device serial number, real-name entity information, or document number.

[0036] In one implementation, a unified anchor verification layer receives a device verification package returned by the registrant client based on a one-time issuance challenge, and calls an anchor verification process that matches the form type of the hardware anchor to verify the device verification package. If the device verification package passes verification, a verification success instruction is sent to the anchor access credential service through the unified anchor verification layer. The anchor access credential service then issues an anchor access credential to the registrant client based on the device verification package.

[0037] Step S106: In response to the agent registration request returned by the registrant client based on the anchor access credential, generate an idempotent key corresponding to the agent registration request, so as to determine the identity registration result corresponding to the agent registration request based on the current registration status corresponding to the idempotent key.

[0038] The agent registration request is a complete identity registration application data packet submitted by the registrant client to the identity issuance center after obtaining the anchor access credential. It includes at least the request number, anchor access credential number, anchor type, namespace, public key of the agent to be bound, registrant identifier, registrant signature, hardware key proof reference, and request time. The idempotent key is a unique string identifier generated by the identity issuance center based on the combination of multiple immutable fields in the agent registration request. It is used to locate and reuse existing processing results in the registration attempt state machine, ensuring that the same logical request produces only one identity registration result. The registration attempt state machine is a state management module in the identity issuance system used to track the lifecycle of the registration process corresponding to each idempotent key. It has five preset states: STARTED, CHECKED, COMMITTED, FAILED_RETRYABLE, and FAILED_FINAL. The identity registration result is a deterministic response returned by the identity issuance center based on the current state of the idempotent key, including: the issued agent identity number and public identity statement (when the status is "submitted successfully"), the finality failure error message (when the status is "finality failure"), or the retry prompt (when the status is "enabled" or "verified").

[0039] In one implementation, the identity issuance center performs the following operations: receiving a smart agent registration request returned by the registrant client based on the anchor access credential; extracting the registrant identifier, namespace, request number, and public key of the smart agent to be bound from the smart agent registration request to generate an idempotent key corresponding to the smart agent registration request; querying the current registration state corresponding to the idempotent key in the registration attempt state machine; and performing the corresponding operation based on the current registration state obtained from the query to obtain the identity registration result.

[0040] Based on the foregoing embodiments, this invention provides a specific implementation of a method for issuing agent identities. This method establishes "the non-exportable private key within the hardware participating in the issuance process in real time" as a necessary condition for the birth of an agent identity. The hardware anchor generates or holds the agent identity private key within the security boundary and performs a signature on the one-time issuance challenge. The unified anchor verification layer issues an anchor access credential after verifying the validity of the hardware signature, device proof, external anchor source status, and registration entity relationship. The identity issuance center can only issue an agent identity when all verifications—anchor access credential, registrant signature, hardware key holding proof, namespace, public key uniqueness, and idempotent state—pass, and simultaneously writes this information to the identity master file and the IDENTITY_ISSUED event. Compared with existing solutions, the embodiments of the present invention do not use hardware certificates as ordinary login credentials, nor do they supplement device materials after identity issuance. Instead, they organically integrate the issuance challenge, hardware key holding proof, anchor access credential, registration application package, public key unique index and IDENTITY_ISSUED event into a complete identity birth chain, thereby effectively blocking identity impersonation caused by copying identity claims, replaying registration packages, migrating software private keys or repeatedly registering the same public key.

[0041] The specific implementation process is as follows: First see Figure 2 The diagram shows a smart agent identity issuance chain where the private key does not leave the hardware. It illustrates the following components: hardware anchor and hardware key slot 10, issuance challenge module 20, unified anchor verification layer 30, anchor access credential 40, registration agent client 50 (i.e., registration client), identity issuance center 60, registration attempt state machine 70, identity master file 80, issuance event 90, and external verification audit 100.

[0042] (i) The hardware anchor and hardware key slot 10 can be AI-eSIM, eUICC, iSIM, U-Key, TPM, HSM, smart card, security chip, trusted gateway, or terminal security module. The hardware key slot generates or stores the agent's identity private key within the hardware security boundary and sets the private key attribute to be non-exportable. External entities can only request the hardware to sign a specified challenge and cannot read the plaintext of the private key.

[0043] (ii) The issuance challenge module 20 receives the issuance challenge request sent by the registrant client and generates a one-time issuance challenge in response to the request. A one-time issuance challenge includes at least the challenge_id, a random number, issuance time, expiration time, expected anchor type, namespace, registration session identifier, and a public key digest to be bound. The one-time issuance challenge is used to constrain the registration session corresponding to the issuance challenge request, the specified hardware anchor, and the public key to be issued within the same time window defined by the issuance time and expiration time.

[0044] Specifically, the issuance challenge module 20 performs the following operations: The first step is to receive the issuance challenge request sent by the registrant's client through a secure transmission protocol; this request must contain at least the registrant's identifier, the expected hardware anchor type, and the namespace; The second step is to call the operating system's built-in true random number generator to generate a random number with a length of 32 bytes; The third step is to obtain the current precise time of the system as the issuance time, and add the preset validity period (default is three minutes) to the issuance time to obtain the expiration time; The fourth step is to extract the registration entity identifier, expected hardware anchor type, and namespace from the challenge request. Fifth step, generate a unique registration session identifier: combine the issuance timestamp, the current process identifier and the random number generated in the second step into a byte stream, perform the national cryptographic hash algorithm operation on the byte stream, and take the first sixteen bytes of the operation result as the registration session identifier; Step 6: Perform the national cryptographic hash algorithm operation on the public key of the agent to be bound to obtain the digest of the public key to be bound; Step 7: Generate challenge identifier: Call the globally unique identifier generator to generate a string that conforms to the UUID version four specification, as the challenge identifier; Step 8: Concatenate the challenge identifier, the random number generated in step 2, the issuance time obtained in step 3, the expiration time obtained in step 3, the expected hardware anchor type extracted in step 4, the namespace extracted in step 4, the registration session identifier generated in step 5, and the public key digest to be bound obtained in step 6 into a byte stream according to the preset field order. The ninth step is to encapsulate the byte stream into a structured data object, forming a one-time issuance challenge; Step 10: Store the one-time issuance challenge in the challenge storage area, set its status to "unused", and record the generation timestamp; Step 11: Return the one-time issuance challenge to the registrant's client.

[0045] (iii) The unified anchor verification layer 30 receives the device verification package returned by the registrant client based on the one-time issuance challenge, and calls the anchor verification process that matches the form type of the hardware anchor to verify the device verification package; if the device verification package fails to pass the verification, it sends a verification failure instruction to the anchor access credential service; if the device verification package passes the verification, it sends a verification success instruction to the anchor access credential service.

[0046] Specifically, the unified anchor verification layer 30 performs the following operations: The first step is to receive the device verification package returned by the registrant's client based on the one-time issuance challenge; The second step is to parse the device proof packet and extract the declared anchor types within it; The third step is to select the corresponding anchor verification process based on the anchor type: If the anchor type is an AI-enhanced embedded user identification module (AI-eSIM), then call the operator's open interface to obtain the online status and operator signature of the AI-enhanced embedded user identification module, and verify that the operator signature is valid and the online status is active. If the anchor type is Trusted Platform Module (TPM), then parse the Quote, endorsement key certificate chain, and authentication key certificate chain in the device proof packet, and verify that the certificate chain is complete and trustworthy and the Quote is valid. If the anchor type is a Universal Key Token (U-Key), then the certificate chain in the device proof packet is parsed and verified that the certificate chain was issued by a trusted root certificate and has not been revoked; If the anchor type is Hardware Security Module (HSM), then parse the remote certification report in the device certification package and verify that the report is signed by a pre-set trusted third-party key and that the certification time is within the validity period; The fourth step is to synchronously perform challenge status verification: query the challenge storage area to confirm that the one-time issuance challenge exists; compare the current system time with the expiration time recorded in the challenge to confirm that it has not expired; query the used challenge record table to confirm that the challenge identifier has not been marked as used. Step 5: Perform hardware signature overlay verification: Use the public key of the agent to be bound attached to the device proof package to verify the challenge identifier, random number, namespace, expected anchor type, registration session identifier and public key digest to be bound contained in the one-time issuance challenge. Step 6: Perform device-registration entity relationship verification: Compare the device binding summary in the device proof package with the pre-stored device binding summary associated with the registration entity information submitted by the registrant client to confirm that the two are consistent; Step 7: If all the above verifications are successful, send a verification success command to the anchor access credential service. Step 8: If any verification fails, a verification failure instruction is sent to the anchor access credential service. The verification failure instruction carries a corresponding failure reason code, which includes a challenge expired code, an invalid signature code, an anchor type mismatch code, a device status failure code, a public key missing code, or a subject relationship invalid code.

[0047] (iv) Anchor Access Credential Service 40: Upon receiving a verification failure instruction, the service refuses to issue an anchor access credential. Upon receiving a successful verification instruction, the service issues an anchor access credential to the registrant's client based on the device proof packet. The anchor access credential is an intermediate qualification credential before identity issuance and is not a public identity statement. Its fields may include credential number, registrant identifier or anonymous reference, namespace, anchor type, anchor verification method, device binding summary, source proof summary, status pointer, validity period, and signature.

[0048] Specifically, the anchor access credential service 40 performs the following operations: The first step is to receive instructions sent by the unified anchor verification layer; The second step is to parse the instruction and determine whether it is a verification failure instruction or a verification success instruction. The third step is to read the failure reason code carried in the instruction if the verification fails; generate the corresponding error message based on the failure reason code; return the error message to the registration client and terminate the subsequent processing; do not generate anchor access credentials and do not write any credential records. The fourth step, if the verification is successful, is to extract the anonymous reference of the registered entity, the anchor type, the device binding summary, and the source proof summary from the device proof package; Step 5: Generate anchor access credential number: Call the globally unique identifier generator to generate a string that conforms to the UUID version four specification; Step 6: Construct the anchor access credential payload: Organize the anchor access credential number generated in Step 5, the anonymous reference of the registration subject extracted in Step 4, the namespace, anchor type, anchor verification method, device binding digest, source proof digest, status pointer, validity period and signature algorithm identifier into structured data according to the preset field order; Step 7: Using the private key of the anchor access credential service, execute the national cryptographic digital signature algorithm on the payload constructed in step 6 to generate a signature; Step 8: Attach the signature to the payload and encapsulate it as an anchor access credential in the format of a Structured Data Encrypted Network Token (SD-JWT). Step 9: Store the anchor access certificate in the anchor certificate storage area, set its status to "valid", and record the issuance timestamp; Step 10: Return the anchor access certificate to the registrant's client.

[0049] (v) The registrant Agent client 50 uses its own signature key to digitally sign the anchor access credential number, namespace, agent public key, anchor type and request number to form the registrant signature; the Agent client calls the hardware anchor to perform a signature operation on the one-time issuance challenge held by the non-exportable agent identity private key to generate a hardware key holding certificate.

[0050] (vi) After receiving the registration application package, the Identity Issuance Center 60 sequentially verifies the validity of the registrant's signature, the legality of the anchor access certificate, the authenticity of the hardware key certificate, the namespace ownership permissions, and the uniqueness of the public key of the smart agent to be bound. After all verifications are passed, a unique smart agent identity number is assigned, and a public identity statement and accompanying metadata certificate are issued. The public identity statement can adopt SD-JWT, CWT, X.509 extended certificate, DID Document reference, platform internal signature statement, or other verifiable certificate formats.

[0051] (vii) The registration attempt state machine 70 records the registration process with idempotent keys; the idempotent keys are generated by combining the registration subject identifier, namespace, request number and public key of the smart agent to be bound; its preset states include at least: STARTED, CHECKED, COMMITTED, FAILED_RETRYABLE and FAILED_FINAL; among them, only when the state is COMMITTED is it considered to be the birth fact of a valid smart agent identity.

[0052] Specifically, the following steps are performed through the identity issuance center: The first step is to receive the agent registration request returned by the registrant client based on the anchor access credential.

[0053] The second step is to extract the registration entity identifier, namespace, request number, and public key of the entity to be bound from the entity registration request, in order to generate the idempotent key corresponding to the entity registration request.

[0054] In one implementation, the payload of the agent registration request is parsed to extract the registration subject identifier, namespace, request number, and public key of the agent to be bound; the four are concatenated into a byte stream in the order of "registration subject identifier | namespace | request number | public key of the agent to be bound"; the national cryptographic hash algorithm is performed on the byte stream, and the first 32 bytes of the result are taken as the idempotent key.

[0055] The third step is to query the current registration status corresponding to the idempotent key in the registration attempt state machine.

[0056] Fourth, if there is no current registration state corresponding to the idempotent key in the registration attempt state machine, then if the agent registration request is verified, an identity issuance transaction is performed. The identity issuance transaction includes at least allocating an agent identity number and constructing a public identity statement to obtain the identity registration result.

[0057] In one implementation, if the query result in step three is empty, the combined verification process is initiated: verifying the validity of the registrant's signature; verifying the signature, validity period, registration entity identifier, namespace, and anchor type of the anchor access credential; verifying the matching of the challenge number, agent public key, device binding digest, signature time, and anchor type in the hardware key holding certificate; verifying the namespace ownership permissions; verifying that the public key of the agent to be bound is not occupied by other valid identity files; if all verifications pass, the database transaction is initiated: calling the unique identifier generator to allocate the agent identity number; constructing a public identity statement (including identity number, issuer, issuance time, validity period, anchor type, state pointer, and SM2 signature); writing the identity number, registration entity identifier, anchor access credential number, anchor type, device binding digest, and state bit position into the identity file; establishing a mapping from the public key to the identity number of the agent to be bound in the public key unique index; writing the IDENTITY_ISSUED event; updating the state of the idempotent key in the registration attempt state machine to "committed successfully"; committing the transaction; and using the agent identity number and public identity statement as the identity registration result.

[0058] Fifth step: If the current registration status corresponding to the idempotent key is "submission successful", then read the identity master file corresponding to the idempotent key and use the agent identity number and public identity declaration recorded in the identity master file as the identity registration result.

[0059] In one implementation, if the status found in the third step is "submission successful", then the corresponding record is read from the identity master file storage area according to the identity master file identifier associated with the idempotent key; the agent identity number and public identity statement are extracted from it; the two are combined into an identity registration result and returned.

[0060] Step 6: If the current registration status corresponding to the idempotent key is a retryable failure status, then if the current number of retries has not reached the preset threshold, the identity issuance transaction will be retried and the number of retries will be updated; if the current number of retries has reached the preset threshold, then the current registration status corresponding to the idempotent key will be updated to the final failure status.

[0061] In one implementation, if the status found in the third step is retryable failure, the retry counter value in the record is read; if the value is less than a preset threshold, the retry counter is incremented by one and written back, and the combined verification and transaction process in the fourth step is re-executed; if the value is equal to or greater than the preset threshold, the status corresponding to the idempotent key is updated to final failure, and no operation of writing to the identity master file or event is performed.

[0062] Step 7: If the current registration status corresponding to the idempotent key is a final failure status, then return an error message to the registrant's client.

[0063] If the status found in the third step is a final failure, then based on the failure reason code associated with that status, generate the corresponding error message (such as "Invalid anchor access certificate", "Public key already occupied", "Registration party signature invalid"); encapsulate the error message into a standard response body and return it to the registration party client through a secure transmission protocol.

[0064] In one example, registering idempotency can be achieved through a unique database index, distributed locks, transaction outboxes, message deduplication tables, registering a session state machine, or a counter within a trusted execution environment.

[0065] (viii) Identity Master File and Public Key Unique Index 80 is used to store the identity number, registration subject reference, anchor access credential number, anchor type, device binding summary, status bit position and the public key of the smart agent to be bound; wherein, the public key unique index of the smart agent to be bound ensures that the same public key is associated with at most one identity record in a valid state.

[0066] (ix) When the identity is successfully issued, the signing event and receipt module 90 writes the IDENTITY_ISSUED event, recording the signing request number, anchor access credential number, smart agent public key, anchor type, device binding summary, status bit position, server-side archived receipt and signing timestamp.

[0067] (x) External verification and auditing module 100 completes identity validity verification and compliance auditing through public identity declaration, real-time challenge signature, status proof and authorized auditing interface.

[0068] In one alternative implementation, for low-level hardware that does not support full remote proof, it can be required to complete challenge signature and device certificate verification, and a lower guarantee level can be recorded in the anchor access credential; for high-risk resources, a higher level hardware proof is required.

[0069] In one implementation, embodiments of the present invention are implemented around the following objects: The HardwareKeySlot records the key slot identifier, algorithm suite, non-exportable flag, agent public key, hardware proof reference, and key state. This object resides within the hardware anchor or hardware management domain and is the technological foundation for private keys not leaving the hardware. Hardware proof can employ eUICC proof, TPM quote, FIDO / Passkey proof, U-Key certificate chain, HSM remote proof, carrier online signature response, vendor certificate chain, or a combination of these proofs.

[0070] The IssuanceChallenge record includes the challenge identifier, random number, expiration time, expected anchor type, namespace, registration session identifier, and public key digest to be bound. This object prevents the replay of old proofs, old registration packages, and cross-namespace material.

[0071] The DeviceAttestationEnvelope records the agent's public key, challenge signature, device certificate reference, carrier or vendor signature, device status, device binding digest, and proof digest. This object proves that this registration request is associated with a genuine hardware anchor. The device binding digest can be formed from an ICCID hash, EID hash, device certificate digest, TPM EK fingerprint, U-Key serial number hash, HSM key tag digest, hardware key slot digest, carrier-signed response digest, or a combination of these.

[0072] The AnchorCredential record includes the registration subject, namespace, anchor type, anchor verification method, device binding digest, source proof digest, state pointer, validity period, and signature. The identity issuance center only consumes the controlled fields of this credential and does not directly process the raw device plaintext. AnchorCredentials can be implemented using platform-internal signature credentials, SD-JWT, CWT, COSE, X.509 extended certificates, verifiable credentials, or database signature records.

[0073] The AgentRegistrationRequest package records the request number, anchor access credential number, anchor type, namespace, agent public key, registrant identifier, registrant signature, hardware key proof reference, and request time.

[0074] The HardwareKeyPossessionProof records the proof number, challenge number, agent public key, hardware signature, signature time, key slot digest, and device binding digest. This proof demonstrates that the applicant actually controls the private key within the hardware, rather than simply submitting a reproducible public key.

[0075] The RegistrationAttempt record contains the attempt number, idempotent key, current status, identity number, error code, submission time, and a summary of the issuance result. It is used to distinguish between failed applications, retryable applications, and submitted identity birth facts.

[0076] The IdentityIssuedEvent event records the identity number, issuance request number, anchor access credential number, anchor type, agent public key, device binding summary, status bit position, and server-side archive receipt. This event serves as the audit entry point for subsequent verification of the identity's origin and device binding.

[0077] In one implementation, see Figure 3 The diagram shows a one-time issuance challenge and hardware key proof flowchart.

[0078] like Figure 3As shown, the registrant first sends a one-time issuance challenge request to the issuance challenge module 20; the issuance challenge module generates a random number and an expiration time, and writes the expected anchor type, namespace, registration session identifier and public key digest of the smart agent to be bound into the challenge data structure; once the challenge is generated, it is uniquely bound to this registration session and automatically expires after the expiration date or after being used.

[0079] Upon receiving the challenge, the hardware anchor and hardware key slot 10 invoke the non-derivative agent identity private key to perform a signature operation within their secure execution boundaries. The signature input includes at least the challenge identifier, random number, namespace, anchor type, public key of the agent to be bound, device binding digest, and signature timestamp. The hardware anchor outputs the hardware signature, public key of the agent to be bound, device proof materials, and device binding digest, which together constitute the device proof package.

[0080] The unified anchor verification layer 30 performs three verifications sequentially: confirming that the one-time issuance challenge exists, has not expired, and has not been used; verifying that the hardware signature covers all specified fields in the challenge and the public key digest of the agent to be bound; and verifying the validity of the corresponding external anchor source according to the anchor type declared in the device proof package—for AI-enhanced embedded user identification module (AI-eSIM), verifying the operator's online status and operator signature; for Trusted Platform Module (TPM), verifying the Quote and endorsement key certificate chain and authentication key certificate chain; and for Universal Key Token (U-Key) or Hardware Security Module (HSM), verifying the certificate chain, key tag digest, or remote proof report.

[0081] If any of the following situations occur: challenge expired, hardware signature invalid, anchor type mismatch, device status failure, submission of only public key without hardware signature, or the relationship between device proof and registration entity is invalid, the unified anchor verification layer will not send a verification pass instruction to the anchor access credential service.

[0082] Optionally, the signature and digest algorithms can be SM2, SM3, ECDSA-P256, Ed25519, SHA-256, or other algorithm suites that meet the requirements of the deployment region.

[0083] In one implementation, see Figure 4 The diagram illustrates a registration attempt state machine, idempotent keys, and a unique public key index.

[0084] After receiving the registration application packet, the Identity Issuance Center 60 first generates an idempotent key based on the registration entity identifier, namespace, request number, and public key of the smart agent to be bound. If the status corresponding to the idempotent key is "submission successful," it directly returns the original smart agent identity number, public identity statement, and server-side filing receipt. If the status is "retryable failure," it continues processing according to the preset retry strategy or returns a retryable error message. If the status is "final failure," it refuses to submit again.

[0085] For the first idempotent key processed, the system creates a new record in the registration attempt state machine and sets its state to STARTED; then performs combined verification: verifying the format of the registration application package and the validity of the public key encoding of the agent to be bound; verifying the signature of the registrant; verifying the signature, validity period, registration subject identifier, namespace, and anchor type of the anchor access credential; verifying the challenge identifier, public key of the agent to be bound, device binding digest, signature timestamp, and anchor type in the hardware key holding certificate; verifying the namespace ownership permissions; and checking whether the public key of the agent to be bound has been occupied by another valid identity master.

[0086] After all verifications pass, the system initiates an identity issuance transaction. This transaction includes at least the following: assigning a unique agent identity number, allocating state bit positions in the off-chain state bitmap, constructing a public identity statement, constructing metadata credentials, writing identity information into the identity master file, establishing a mapping between the public key of the agent to be bound and the identity number in the public key unique index, writing the IDENTITY_ISSUED event, generating and writing a server-side filing receipt, and updating the state of the idempotent key in the registration attempt state machine to "committed successfully".

[0087] If a network timeout or temporary service failure occurs before the transaction is committed, the system updates the idempotent key status to retryable failure (FAILED_RETRYABLE); if the verification fails due to invalid anchor access credentials, duplicate public keys of the agent to be bound, invalid signature of the registrant, or invalid hardware key proof, the status is updated to final failure (FAILED_FINAL); in the final failure state, no identity master is generated, nor is the IDENTITY_ISSUED event written.

[0088] In one implementation, see Figure 5 The diagram shows a visibility boundary graph of a public credential bound to an internal device.

[0089] The public identity statement includes the agent's identity number, issuer identifier, validity period, anchor type, state pointer, signature algorithm identifier, and the public key of the agent to be bound or its verification materials; it does not include real-name subject information, integrated circuit card identification code (ICCID), embedded user identification module identifier (EID), operator account information, document number, original device serial number, hardware private key, or plaintext of complete device proof.

[0090] The identity metadata credential includes the anchor verification method, anchor access credential number, anchor guarantee level, independent state pointer, and issuer signature, and is specifically used for authorization auditing or high-level identity verification scenarios.

[0091] The internal identity master file stores the registration subject reference, anchor access credential number, device binding summary, hardware binding material summary, status bit position, and the current status of the master file.

[0092] When verifying a smart agent's request, an external verifier can require the agent to sign the real-time challenge using the public key of the smart agent to be bound in the public identity statement, and combine the state proof to determine the validity of the identity. Even if an attacker copies the public identity statement, they cannot call the non-exportable private key in the hardware on another device to complete the real-time signature. Even if the historical registration package is replayed, it will be rejected because the challenge has expired, the idempotent key already exists, or the public key unique index conflict.

[0093] In authorized audit scenarios, auditors can locate the IDENTITY_ISSUED event through the agent's identity number, and then use the associated anchor access credential number and hardware binding material summary through the event to trace the type of hardware anchor bound when the identity was created, the original issuance request, and the ownership relationship of the registered entity.

[0094] In summary, the embodiments of the present invention have at least the following characteristics: 1. By signing the one-time issuance challenge using the non-exportable private key of the agent's identity within the hardware anchor, identity migration caused by software-side private key copying is blocked; attackers can only copy public credentials or identity statements and cannot reproduce the signature on other devices, thus they cannot regain control over the same identity.

[0095] Second, by using a closed-loop link of one-time issuance challenge, hardware signature, device proof package and anchor access credential, the verification and solidification of hardware key holding facts are completed at the identity birth stage, avoiding the introduction of device materials as post-event supplementary items into the identity issuance process.

[0096] Third, by incorporating the challenge random number, validity period, anchor type, namespace, and public key digest of the agent to be bound into the signature input, the system effectively blocks replay of old proofs, impersonation across namespaces, and fake registration behavior that only submits the public key without hardware signature.

[0097] Fourth, by using anchor access credentials as a controlled carrier of hardware proof results, the original device materials (such as ICCID, EID, real-name information) are logically isolated from the core identity issuance process, enabling the identity issuance center to reliably verify the hardware key holding conclusion, while preventing the exposure of plaintext device identifiers in public credentials.

[0098] Fifth, by employing a collaborative mechanism involving a registration attempt state machine, idempotent keys, database transaction commits, and a unique index of the public key of the agent to be bound, we ensure that in scenarios involving concurrent requests or network retries, the same logical registration request produces only one valid identity result.

[0099] VI. By writing the IDENTITY_ISSUED event and the server-side filing receipt, the key elements at the time of identity creation are fully solidified, forming a verifiable, traceable, and non-repudiable audit evidence chain, supporting subsequent judicial-level proof of the relationship between the issuance request, hardware anchor type, public key of the smart agent to be bound, and device binding digest.

[0100] Based on the foregoing embodiments, this invention provides an intelligent agent identity issuance system, see [link to previous embodiment]. Figure 6 The diagram shown illustrates the structure of an intelligent agent identity issuance system, which mainly includes the following components: The issuance challenge module is used to respond to the issuance challenge request sent by the registrant's client and generate a one-time issuance challenge; The unified anchor verification layer and anchor access credential service are used to respond to the device proof packet returned by the registrant client based on the one-time issuance challenge. If the device proof packet is verified, the anchor access credential is issued to the registrant client. The device proof packet is formed by the registrant client signing the one-time issuance challenge using the private key of the smart agent identity configured to be non-exportable in the hardware anchor. The identity issuance center is used to respond to the agent registration request returned by the registrant client based on the anchor access credential, generate the idempotent key corresponding to the agent registration request, and determine the identity registration result corresponding to the agent registration request based on the current registration status corresponding to the idempotent key.

[0101] The device provided in this embodiment of the invention has the same implementation principle and technical effect as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0102] This invention provides an electronic device, specifically, the electronic device includes a processor and a memory; the memory stores a computer program, which, when run by the processor, executes the method described in any of the above embodiments.

[0103] Figure 7 The present invention provides a schematic diagram of the structure of an electronic device 700, which includes a processor 70, a memory 71, a bus 72 and a communication interface 73. The processor 70, the communication interface 73 and the memory 71 are connected through the bus 72. The processor 70 is used to execute executable modules, such as computer programs, stored in the memory 71.

[0104] The memory 71 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 73 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc.

[0105] Bus 72 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0106] The memory 71 is used to store programs. After receiving an execution instruction, the processor 70 executes the programs. The method executed by the device for defining the flow process disclosed in any of the foregoing embodiments of the present invention can be applied to the processor 70 or implemented by the processor 70.

[0107] The processor 70 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 70 or by instructions in software form. The processor 70 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 71. Processor 70 reads the information in memory 71 and, in conjunction with its hardware, completes the steps of the above method.

[0108] The computer program product of the readable storage medium provided in the embodiments of the present invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the foregoing method embodiments. For specific implementation, please refer to the foregoing method embodiments, which will not be repeated here.

[0109] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0110] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for issuing identity for an intelligent agent, characterized in that, The method is applied to an identity issuance system, and the method includes: In response to the issuance challenge request sent by the registrant's client, a one-time issuance challenge is generated; In response to the device verification packet returned by the registrant client based on the one-time issuance challenge, if the device verification packet is verified, an anchor access credential is issued to the registrant client. The device verification packet is formed by the registrant client signing the one-time issuance challenge using the smart agent identity private key configured to be non-exportable in the hardware anchor. In response to the agent registration request returned by the registrant client based on the anchor access credential, an idempotent key corresponding to the agent registration request is generated, so as to determine the identity registration result corresponding to the agent registration request based on the current registration status corresponding to the idempotent key.

2. The intelligent agent identity issuance method according to claim 1, characterized in that, The identity issuance system includes an issuance challenge module; in response to an issuance challenge request sent by the registrant client, a one-time issuance challenge is generated, including: The issuance challenge module receives the issuance challenge request sent by the registrant client and generates a one-time issuance challenge for the issuance challenge request. The one-time issuance challenge is used to constrain the registration session corresponding to the issuance challenge request, the specified hardware anchor, and the public key to be issued within the same time window defined by the issuance time and the expiration time.

3. The intelligent agent identity issuance method according to claim 1, characterized in that, The identity issuance system includes a unified anchor verification layer and an anchor access credential service; in response to the device verification packet returned by the registrant client based on the one-time issuance challenge, if the device verification packet passes verification, an anchor access credential is issued to the registrant client, including: Through the unified anchor verification layer, the device verification package returned by the registrant client based on the one-time issuance challenge is received, and the anchor verification process matching the form type of the hardware anchor is invoked to verify the device verification package; If the device verification package fails verification, a verification failure instruction is sent to the anchor access credential service through the unified anchor verification layer, and the anchor access credential service refuses to issue the anchor access credential. If the device verification package passes verification, a verification success command is sent to the anchor access credential service through the unified anchor verification layer. The anchor access credential service then issues an anchor access credential to the registrant client based on the device verification package.

4. The intelligent agent identity issuance method according to claim 1, characterized in that, The identity issuance system further includes an identity issuance center; in response to the agent registration request returned by the registrant client based on the anchor access credential, it generates an idempotent key corresponding to the agent registration request, and determines the identity registration result corresponding to the agent registration request based on the current registration status corresponding to the idempotent key, including: The following operations are performed through the identity issuance center: Receive the agent registration request returned by the registration client based on the anchor access credential; Extract the registration entity identifier, namespace, request number, and public key of the smart entity to be bound from the smart entity registration request to generate the idempotent key corresponding to the smart entity registration request; Query the current registration status in the registration attempt state machine corresponding to the idempotent key; If the current registration state corresponding to the idempotent key does not exist in the registration attempt state machine, then if the agent registration request is verified, an identity issuance transaction is performed. The identity issuance transaction includes at least allocating an agent identity number and constructing a public identity statement to obtain the identity registration result.

5. The intelligent agent identity issuance method according to claim 4, characterized in that, The method further includes: If the current registration status corresponding to the idempotent key is "submission successful", then read the identity master file corresponding to the idempotent key and use the agent identity number and public identity declaration recorded in the identity master file as the identity registration result.

6. The intelligent agent identity issuance method according to claim 4, characterized in that, The method further includes: If the current registration status corresponding to the idempotent key is a retryable failure status, then if the current number of retries has not reached the preset threshold, the identity issuance transaction will be retried and the number of retries will be updated; if the current number of retries reaches the preset threshold, then the current registration status corresponding to the idempotent key will be updated to a final failure status.

7. The intelligent agent identity issuance method according to claim 4, characterized in that, The method further includes: If the current registration status corresponding to the idempotent key is a final failure status, then an error message is returned to the registrant client.

8. A smart agent identity issuance system, characterized in that, include: The issuance challenge module is used to respond to the issuance challenge request sent by the registrant's client and generate a one-time issuance challenge; A unified anchor verification layer and anchor access credential service are used to respond to the device verification packet returned by the registrant client based on the one-time issuance challenge. If the device verification packet is verified, the registrant client issues an anchor access credential to the registrant client. The device verification packet is formed by the registrant client signing the one-time issuance challenge using the private key of the smart agent identity configured to be non-exportable in the hardware anchor. The identity issuance center is used to respond to the agent registration request returned by the registrant client based on the anchor access credential, generate an idempotent key corresponding to the agent registration request, and determine the identity registration result corresponding to the agent registration request based on the current registration status corresponding to the idempotent key.

9. An electronic device, characterized in that, The method includes a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions that, when invoked and executed by a processor, cause the processor to perform the method according to any one of claims 1 to 7.

Images