Key escrow method, device and equipment based on SIM (Subscriber Identity Module) card, medium and program product

Abstract

The invention discloses a secret key escrow method and device based on an SIM card, equipment, a medium and a program product, and relates to the technical field of identity authentication, and the method applied to terminal equipment comprises the following steps: sending a first request to a TSM platform, receiving a first instruction, and installing a first escrow application in a first SIM card in the terminal equipment based on the first instruction; obtaining a master key pair generated based on the first hosting application, and sending first information to the TSM platform; sending a second request to an identity service platform pre-accessed by the business application program APP, receiving a DID sent by the identity service platform in response to the second request, and sending the DID to the TSM platform; the second request carries a public key in the master key pair, and the DID is generated by the identity service platform based on the public key in the master key pair; under the condition that the first SIM card is replaced by the second SIM card, sending a third request to the TSM platform, and receiving a DID and hosting information sent by the TSM platform; and writing a master key pair corresponding to the DID and the first information into the second SIM card.

Description

Technical Field

[0001] This application relates to the field of identity authentication technology, and in particular to a key escrow method, apparatus, device, medium and program product based on a SIM card. Background Technology

[0002] Decentralized Identifier (DID) authentication employs a decentralized approach, preventing identity data from being controlled by a single centralized authority, thereby improving data security and privacy. DID authentication, through technologies such as Verifiable Credentials, allows users to manage their own identity data independently, without relying on third-party authentication. This enables users' identity data to be verified by other entities (such as businesses and organizations), ensuring the authenticity and integrity of the data. However, in existing distributed digital identity technologies, users' digital identities still rely on client software or cloud storage services. When users relocate their devices or delete the client, the original distributed identity information needs to be regenerated, making it difficult for users to manage their own identity information. Summary of the Invention

[0003] This application provides a SIM card-based key escrow method, apparatus, device, medium, and program product that can enhance users' management of their own identity information without regenerating the original distributed identity information when a user moves a device or deletes the client.

[0004] In a first aspect, embodiments of this application provide a key escrow method based on a SIM card, applied to a terminal device, the method comprising: Send a first request to the Trusted Service Management (TSM) platform, receive a first instruction from the TSM platform in response to the first request, and install a first managed application on the first SIM card in the terminal device based on the first instruction; Obtain the master key pair generated based on the first hosting application, and send the first information to the TSM platform, the first information including the hosting information corresponding to the master key pair; A second request is sent to the identity service platform that the business application (APP) has pre-connected to, the identity service platform receives the DID sent in response to the second request, and the DID is sent to the TSM platform; the second request carries the public key in the master key pair, and the DID is generated by the identity service platform based on the public key in the master key pair. When the terminal device replaces the first SIM card with the second SIM card, it sends a third request to the TSM platform and receives the DID and the managed information sent by the TSM platform in response to the third request; Write the master key pair corresponding to the DID and the first information into the second SIM card.

[0005] Optionally, sending a first request to the Trusted Service Management (TSM) platform and receiving a first instruction from the TSM platform in response to the first request includes: In response to the operation instruction of the business APP, the first request is generated; wherein, the operation instruction includes a first signature, the first signature is obtained by signing the identification information of the target user with a first private key, the first private key is the private key in the first key pair corresponding to the business APP, and the target user is the user who logs into the business APP; Send the first request to the TSM platform, the first request carrying the first signature; The first instruction sent by the TSM platform in response to the first request is received, and the first instruction is used to instruct the first SIM card to install the first managed application under the first security domain.

[0006] Optionally, the first information further includes authorization information, and sending the first information to the TSM platform includes: In response to the authorization instruction from the business APP for the key escrow service, the authorization information of the key escrow service is obtained; The hosting information corresponding to the master key pair is generated through the first hosting application; Send the hosting information and the authorization information to the TSM platform.

[0007] Optionally, the step of sending a second request to the identity service platform pre-connected to the business application (APP) and receiving the DID sent by the identity service platform in response to the second request includes: Based on the private key in the first key pair corresponding to the business APP, the second information associated with the business APP is signed to obtain a second signature; wherein, the second information includes at least one of the authorization information, login information and target user identification information, and the target user is the user who logs into the business APP; Send the second request to the identity service platform; wherein the second request carries the second signature; Receive the DID generated by the identity service platform when the second signature verification is successful.

[0008] Optionally, after sending the DID to the TSM platform, the method further includes: Receive the third instruction sent by the TSM platform; If the first managed application has already generated a sub-key pair corresponding to the business APP, the DID is written to the first SIM card based on the third instruction; When the business APP initiates identity authentication, it sends the DID to the TSM platform and receives the identification information of the business APP sent by the TSM platform based on the managed record table; wherein, the managed record table is used to store the correspondence between the DID and the identification information of the business APP; Based on the identification information of the business APP, obtain the matching rules corresponding to the identification information of the business APP pre-written in the first managed application; The sub-key pair corresponding to the business APP is determined based on the matching rules.

[0009] Optionally, when the terminal device replaces the first SIM card with the second SIM card, sending a third request to the TSM platform includes: When the terminal device replaces the first SIM card with the second SIM card, the authorization information is encrypted based on the second public key, and the encrypted authorization information is signed based on the first private key to obtain a third signature; Send the third request to the TSM platform, the third request including the third signature to be verified; The second public key is the public key that the TSM platform pre-sent to the terminal device, and the first private key is the private key in the first key pair corresponding to the business APP.

[0010] Optionally, receiving the DID and the hosting information sent by the TSM platform in response to the third request includes: If the third signature verification is successful, a second instruction sent by the TSM platform in response to the third request is received, the second instruction including the DID and the first information; After receiving the DID and the hosting information sent by the TSM platform in response to the third request, the method further includes: Based on the second instruction, a second managed application is installed within the second security domain of the second SIM card; The second instruction carries the second security domain, and the second managed application is used to write the DID and the master key pair into the second SIM card.

[0011] Secondly, embodiments of this application provide a key escrow method based on a SIM card, applied to a TSM platform, the method comprising: Receive the first request sent by the terminal device; In response to the first request, a first instruction is sent to the terminal device, the first instruction being used to instruct the terminal device to install a first managed application on the first SIM card; The terminal device receives first information, the first information including managed information corresponding to a master key pair, wherein the master key pair is a key pair generated by the first managed application. Receive the DID sent by the terminal device, wherein the DID is generated by the identity service platform based on the public key in the master key pair; The system receives a third request from the terminal device and, in response to the third request, sends the DID and the hosting information to the terminal device.

[0012] Optionally, before the receiving terminal device sends the first request, the method further includes: The system receives a fourth request from the operation server of the business app; wherein the business app is an app pre-deployed on the terminal device, and the fourth request carries the identification information of the business app. If the operating server is connected to the identity service platform, in response to the fourth request, perform at least one of the following: Configure the third security domain and third key pair corresponding to the identity service platform, and send the third security domain and third key pair to the identity service platform; The identification information of the business APP is entered into the whitelist sequence of the TSM platform; Configure a service interface, which is used to provide access services for the business APP.

[0013] Optionally, after receiving the DID sent by the terminal device, the method further includes any one or more of the following: The DID is stored in a pre-built managed record table, which is used to store the correspondence between the DID and the identification information of the business APP; If the first managed application has generated a sub-key pair corresponding to the business APP, a third instruction is sent to the terminal device, the third instruction being used to instruct the DID to be written to the first SIM card; When the business APP initiates identity authentication, it receives the DID sent by the terminal device and returns the identification information of the business APP corresponding to the DID in the managed record table to the terminal device.

[0014] Optionally, in response to the third request, sending the DID and the hosting information to the terminal device includes: In response to the third request, the third signature carried in the third request is verified based on the second private key in the second key pair corresponding to the TSM platform and the first private key in the first key pair corresponding to the business APP. If the third signature verification is successful, a second instruction is sent to the terminal device; The second instruction carries the DID and the managed information, and also carries a second security domain.

[0015] Thirdly, embodiments of this application provide a key escrow method based on a SIM card, applied to an identity service platform, the method comprising: The terminal device receives a second request, which carries the public key of a master key pair. The master key pair is a key pair generated based on a first managed application. The first managed application is an application installed on the first SIM card in the terminal device. In response to the second request, a DID corresponding to the terminal device is generated based on the public key in the master key pair; Send the DID to the terminal device.

[0016] Optionally, before receiving the second request sent by the terminal device, the method further includes: Receive a fifth request sent by the operation server of the business APP; wherein, the business APP is an APP pre-deployed on the terminal device; In response to the fifth request, the third public key of the third key pair is sent to the operation server. The third key pair is a key pair pre-configured by the identity service platform. Receive the first public key sent by the operation server, wherein the first public key is the public key in the first key pair corresponding to the business APP.

[0017] Optionally, in response to the second request, generating the DID corresponding to the terminal device based on the public key in the master key pair includes: In response to the second request, the second signature carried in the second request is verified based on the first public key; If the second signature verification passes, the DID is generated based on the public key in the master key pair.

[0018] Fourthly, embodiments of this application also provide a SIM card-based key escrow device, applied to a terminal device, the device comprising: The first sending module is configured to send a first request to the Trusted Service Management (TSM) platform, receive a first instruction sent by the TSM platform in response to the first request, and install a first managed application on the first SIM card in the terminal device based on the first instruction. The first acquisition module is used to acquire the master key pair generated based on the first hosting application and send first information to the TSM platform, the first information including hosting information corresponding to the master key pair; The second sending module is used to send a second request to the identity service platform that the business application (APP) has pre-accessed, receive the DID sent by the identity service platform in response to the second request, and send the DID to the TSM platform; the second request carries the public key in the master key pair, and the DID is generated by the identity service platform based on the public key in the master key pair. The third sending module is used to send a third request to the TSM platform when the terminal device replaces the first SIM card with the second SIM card, and to receive the DID and the managed information sent by the TSM platform in response to the third request; The first writing module is used to write the DID and the master key pair corresponding to the first information into the second SIM card.

[0019] Fifthly, embodiments of this application also provide a SIM card-based key escrow device applied to a TSM platform, the device comprising: The first receiving module is used to receive the first request sent by the terminal device; The fourth sending module is used to send a first instruction to the terminal device in response to the first request, wherein the first instruction is used to instruct the terminal device to install a first managed application on the first SIM card; The second receiving module is used to receive first information sent by the terminal device, the first information including managed information corresponding to the master key pair, the master key pair being a key pair generated by the first managed application; The third receiving module is used to receive the DID sent by the terminal device, wherein the DID is generated by the identity service platform based on the public key in the master key pair; The fourth receiving module is used to receive the third request sent by the terminal device, and in response to the third request, send the DID and the hosting information to the terminal device.

[0020] Sixthly, embodiments of this application also provide a SIM card-based key escrow device applied to an identity service platform, comprising: The fifth receiving module is used to receive a second request sent by the terminal device. The second request carries the public key in the master key pair. The master key pair is a key pair generated based on the first managed application. The first managed application is an application installed on the first SIM card in the terminal device. The first generation module is configured to, in response to the second request, generate the DID corresponding to the terminal device based on the public key in the master key pair; The fifth sending module is used to send the DID to the terminal device.

[0021] In a seventh aspect, embodiments of this application provide an electronic device, including: a processor, a memory, and a program stored in the memory and executable on the processor. When executed by the processor, the program implements the steps of the SIM card-based key escrow method as described in any one of the first aspects, or implements the steps of the SIM card-based key escrow method as described in any one of the second aspects, or implements the steps of the SIM card-based key escrow method as described in any one of the third aspects.

[0022] Eighthly, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the SIM card-based key escrow method as described in any one of the first aspects, or implements the steps of the SIM card-based key escrow method as described in any one of the second aspects, or implements the steps of the SIM card-based key escrow method as described in any one of the third aspects.

[0023] In a ninth aspect, embodiments of this application also provide a computer program product stored in a storage medium, the computer program product being executed by at least one processor to implement the steps of the SIM card-based key escrow method as described in any one of the first aspects, or the steps of the SIM card-based key escrow method as described in any one of the second aspects, or the steps of the SIM card-based key escrow method as described in any one of the third aspects.

[0024] In this embodiment, the terminal device sends a first request to the TSM platform, receives a first instruction from the TSM platform in response to the first request, and installs a first managed application on the first SIM card in the terminal device based on the first instruction. A master key pair is generated based on the first managed application, and first information, including managed information corresponding to the master key pair, is sent to the TSM platform. The terminal device sends a second request to the identity service platform pre-accessed by the business application (APP), receives a DID from the identity service platform in response to the second request, and sends the DID to the TSM platform; the second request carries the public key from the master key pair, and the DID is generated by the identity service platform based on the public key from the master key pair. If the terminal device replaces the first SIM card with a second SIM card, it sends a third request to the TSM platform, receiving the DID and managed information from the TSM platform in response to the third request. The master key pair corresponding to the DID and the first information is written to the second SIM card. In this way, by storing only the master key pair in the SIM card and using managed information to dynamically generate and manage sub-key pairs, this application can reduce the memory requirement of storing multiple key pairs to only storing the master key pair. When a user changes their SIM card, the terminal device can restore the master key pair in the new SIM card based on the DID identifier and managed information, avoiding key loss and identity invalidation caused by hardware replacement. This ensures that the distributed identity authentication service can be seamlessly continued after the card is changed without user operation, thereby significantly improving system memory efficiency, service continuity and user experience while ensuring key security. Attached Figure Description

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

[0026] Figure 1 This is one of the flowcharts of a key escrow method based on a SIM card in the embodiments of this application; Figure 2 This is a second flowchart of a key escrow method based on a SIM card in an embodiment of this application; Figure 3 This is the third flowchart of a key escrow method based on a SIM card in the embodiments of this application; Figure 4 This is the fourth flowchart of a key escrow method based on a SIM card in the embodiments of this application; Figure 5 This is one of the structural schematic diagrams of a SIM card-based key escrow device in the embodiments of this application; Figure 6 This is a second schematic diagram of a SIM card-based key escrow device in an embodiment of this application; Figure 7 This is the third schematic diagram of a SIM card-based key escrow device in the embodiments of this application; Figure 8 This is one of the schematic diagrams of an electronic device according to an embodiment of this application; Figure 9 This is a second schematic diagram of an electronic device according to an embodiment of this application; Figure 10 This is the third schematic diagram of an electronic device in the embodiments of this application. Detailed Implementation

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

[0028] It's important to note that distributed DID identity authentication employs a decentralized approach, preventing identity data from being controlled by a single centralized authority, thereby enhancing data security and privacy. Users can manage their own identity data independently, without relying on third-party authentication institutions, thus strengthening user autonomy and control. Distributed DID identity authentication, through technologies such as verifiable credentials, allows user identity data to be verified by other entities (such as enterprises and organizations), ensuring the authenticity and integrity of the data.

[0029] The W3C proposed the concept of Distributed Digital Identity (DID) based on blockchain technology. Based on DPKI, users can manage their identities independently, without relying on trusted third parties. Furthermore, identity owners can access their identity data wherever they need it, without depending on a specific identity service provider. However, in existing distributed digital identity technologies, users' digital identities still reside in client software or are stored via cloud services, failing to truly enable users to manage their own identities. Software storage also presents certain security risks. When users relocate their devices or delete the client, the original distributed identity information needs to be regenerated, and the original DID (including the user's DID identifier and public key information, with the DID identifier calculated from the public key information) becomes unusable, causing inconvenience for users. Therefore, a secure carrier for storing DID data is needed, along with escrow keys for users, ensuring that all DID data stored on the blockchain remains valid regardless of whether the secure carrier is lost and reissued or replaced.

[0030] Therefore, to solve the above-mentioned technical solutions, this application provides a key escrow method, apparatus, electronic device, storage medium, and program product based on a SIM card. The embodiments of this application will be described in detail below with reference to the accompanying drawings and specific examples and application scenarios.

[0031] Please see Figure 1 , Figure 1 This is one of the flowcharts of a key escrow method based on a SIM card provided in this application embodiment. The method is applied to a terminal device and specifically includes: Step 101: Send a first request to the Trusted Service Management (TSM) platform, receive a first instruction from the TSM platform in response to the first request, and install a first managed application on the first SIM card in the terminal device based on the first instruction.

[0032] It should be noted that the embodiments of this application can be applied to distributed identity authentication scenarios to provide users with a private key vault service. The distributed identity authentication scenario may include the following components: (1) Identity Provider Platform: As the core registration center of the distributed identity system, it is responsible for generating unique DID identifiers and uploading them to the blockchain to ensure the trustworthiness and immutability of the DIDs. Identity providers can complete security policy configuration (such as security domain allocation and SM2 public key exchange) through the TSM platform, and the TSM platform will include the identity providers in a whitelist. In some embodiments, based on the public key in the master key pair (SM2) generated by the SIM card, the DID identifier is generated using the national cryptographic SM2 algorithm and published to the blockchain and terminal devices.

[0033] (2) Business App Operation Server: This is the backend system of the application service provider, supporting DID-based distributed identity authentication. After successful authentication, business services (such as payment and login) are opened. The operation server can provide an identity authentication interface to receive the user's DID and signature credentials, and verify whether the sub-key pair associated with the DID is valid. After successful authentication, exclusive services (such as Alipay's payment function) are pushed to the user.

[0034] (3) Service App: The client software developed by the identity provider for individual users is the interaction entry point between the terminal device and the SIM card key custody service. By installing the service app on the terminal device, individual users can activate the distributed identity key custody application of the SIM card through the service app. After activation, they can use this DID identity authentication to enjoy the corresponding application services provided by the service provider.

[0035] (4) Trusted Service Manager (TSM) platform: It is the trusted service management hub deployed by the operator, responsible for remote management of SIM cards, distribution of security policies and key escrow services. It provides a platform for identity to complete remote management of SIM cards, and provides key escrow services for each user.

[0036] (5) SIM card: As a security carrier for SIM card applications, it provides human-computer interaction and proactive command capabilities to ensure that key operations are completed in a trusted execution environment.

[0037] (6) Managed Application: Installed in the SIM card, under the premise of meeting security policies, it can provide users with SM2 key pair generation, DID identifier storage and multiple key management capabilities for distributed DID. According to the key security algorithm, a master-slave server approach is adopted to develop the master application interface. Only one master key pair is needed to dynamically generate multiple sets of secondary SM2 key pairs that do not need to be stored, which greatly reduces SIM memory consumption, breaks the SIM memory bottleneck, and can provide SM2 key services to more industry customers. At the same time, only one password (management information or management vector) needs to be managed to manage all keys in the key management box, solving the key loss caused by hardware replacement.

[0038] In the above steps, the terminal device sends a first request to the "Operator TSM Platform (TSM)" through the pre-installed "DID Identity Holder APP (hereinafter referred to as APP)," which is an application to activate the DID identity key deposit box application. This first request can carry the user's mobile phone number and be signed by the APP's SM2 private key to ensure the legitimacy of the request. After verifying the validity of the request signature, the TSM can send a first instruction to the terminal device. The instruction content can include creating a security domain for the first SIM card, configuring the initial security key, and downloading and installing the "Key Custodial SIM Card Application (hereinafter referred to as Card Application)." After receiving the instruction, the terminal device drives the first SIM card to execute the instructions: complete the creation of the security domain, configure the initial key, and install the "Card Application" (i.e., the first custodial application) on the first SIM card, thus completing the application deployment.

[0039] For example, when a user clicks "Activate SIM Card Key Escrow" in the Alipay APP, the Alipay APP signs the mobile phone number with its own private key, generates a request and sends it to TSM. After verification, TSM returns an instruction, so that the terminal device can install the key escrow application in the SIM card security domain DID_APP.

[0040] Thus, this embodiment of the application can replace the existing storage mode that relies on client software or the cloud by deploying the first managed application on a SIM card with hardware encryption features. This achieves hardware-level isolation protection for identity data, physically eliminating the risk of data leakage, tampering, and loss due to device replacement, and significantly improving the storage security of distributed DID identity data. Simultaneously, relying on the TSM platform for SM2 signature verification of requests, creation of dedicated security domains, and initial security key configuration, the legality of application deployment and operational independence are ensured, preventing unauthorized entities from abusing SIM card resources or accessing the application without authorization.

[0041] Step 102: Obtain the master key pair generated based on the first hosting application, and send the first information to the TSM platform, the first information including the hosting information corresponding to the master key pair.

[0042] In this embodiment, the first managed application (i.e., the key-managed SIM card application) installed on the first SIM card can automatically generate a master key pair based on the national cryptographic algorithm SM2. Each application has only one master key pair, which is the core foundation for subsequent derivative subkeys and DID generation. The private key is securely stored in the hardware encryption area of ​​the SIM card and is only used internally for operations such as signing, without being transmitted in plaintext. The public key is fed back to the terminal device through the DID identity APP on the terminal device, enabling the terminal device to obtain the public verification information of the master key pair, providing key parameters for subsequent DID application to the identity service platform.

[0043] Sending the first message to the TSM platform can be done with user authorization: If the user confirms the activation of the key escrow service through the DID identity APP on the terminal device, the first escrow application will calculate and generate an escrow vector D (i.e., escrow information) based on the generated master key pair, and then send the first message to the TSM platform through the DID identity APP on the terminal device (or through a direct secure interaction channel between the first escrow application and the TSM platform). In some embodiments, this first message may be centered on the escrow vector D, and in some scenarios may include auxiliary associated information such as the public key index of the master key pair and the user's mobile phone number. After receiving the first message, the TSM platform will create a dedicated key escrow record table for the current user, bind and store the escrow vector D with the user's identity information, complete the initial information registration for key escrow, and ensure that when the user changes SIM cards later, the master key pair can be recovered through this escrow information to avoid on-chain DID invalidation.

[0044] The above steps ensure key security by storing the master key and private key at the hardware level, achieve key recoverability by reporting escrow information, and establish a data foundation for the association between the master key and subsequent DIDs. This serves as a key bridge connecting application deployment and DID generation, directly solving the core problems of easy key loss and difficulty in escrow in existing technologies.

[0045] Step 103: Send a second request to the identity service platform that the business application (APP) has pre-connected, receive the DID sent by the identity service platform in response to the second request, and send the DID to the TSM platform; the second request carries the public key in the master key pair, and the DID is generated by the identity service platform based on the public key in the master key pair.

[0046] It is understandable that the above steps are the key steps in the key escrow method of the SIM card to generate DID and establish the association between DID and key, and to carry out the reporting of master key pair generation and escrow information, so as to provide the core association basis for ensuring the validity of DID when the card is replaced in the future.

[0047] In the above steps, the terminal device initiates a core operation through the business application (APP): sending a second request to the pre-connected identity service platform. This second request can carry two types of key information: basic application data, which may include the public key from the master key pair, the user's mobile phone number, APP login account, and other identity-related information; and security verification data, which can be signed using the APP's SM private key to ensure that the request data has not been tampered with and that the initiator is a legitimate user, preventing unauthorized entities from impersonating the user to apply for a DID. Furthermore, the identity service platform, as a trusted institution within the distributed authentication system, can prioritize verifying the legitimacy of the request (e.g., verifying the validity of the SM2 signature and checking the integrity of the user's basic information), providing a security prerequisite for subsequent DID generation.

[0048] In some embodiments, after the identity service platform completes the request verification, it can generate a DID and accompanying document based on the public key in the master key pair. The specific process is as follows: Generating a DID identifier: Following the national cryptographic SM2 algorithm rules, a unique DID identifier is calculated using the public key of the master key pair as the core parameter, ensuring a strong binding between the identifier and the user's master key. Subsequent verification of DID ownership can be performed via the public key. Generating a DID document: The document may contain key information such as the DID identifier, the public key of the master key pair, the identity service platform's signature, and DID usage rules. This is used for identity verification in distributed scenarios; for example, enterprises and organizations can use the document to verify the authenticity of user identities. Uploading and returning the DID: The identity service platform uploads the DID document to the blockchain to ensure the DID's public traceability and immutability, conforming to the decentralized characteristics of distributed DIDs. Simultaneously, the generated DID identifier is returned to the terminal device's APP. Thus, the terminal device can receive the DID through the APP, completing the initial acquisition of distributed identity.

[0049] Finally, the terminal device can send the DID to the TSM platform. After receiving the DID, the terminal device must immediately synchronize the DID to the TSM platform, thereby establishing the association between the DID, master key pair, and escrow information. In a specific embodiment, after receiving the DID, the TSM platform can, on the one hand, write the DID into the first escrow application of the first SIM card (i.e., write the DID identifier into the SIM card), ensuring that the user's distributed identity identifier is stored in the SIM hardware carrier. On the other hand, the TSM platform updates the key escrow record table, associating and storing the DID with the escrow information (e.g., escrow information or escrow vector D) corresponding to the master key pair. Before writing the DID, the first escrow application will first verify whether the master key pair associated with the current APP has been generated. Writing the DID is only allowed if the master key pair already exists, avoiding the disconnection between the DID and the key, and preventing invalid identities with DID but no corresponding key.

[0050] Therefore, through the above steps, this application's embodiments generate a DID based on the master key and public key, ensuring a strong binding between the DID and the user's core key, conforming to the specifications for unified distributed DID identity and key. Furthermore, by associating the DID with escrow information through TSM, a traceable and recoverable data foundation is provided for subsequent SIM card replacement recovery. This ensures that even after a user replaces their SIM card, they can still recover the master key pair and DID through the escrow information, guaranteeing the continued validity of on-chain DID documents and transaction records.

[0051] Step 104: When the terminal device replaces the first SIM card with the second SIM card, it sends a third request to the TSM platform and receives the DID and the hosting information sent by the TSM platform in response to the third request.

[0052] In a specific embodiment, after the terminal device replaces the first SIM card with the second SIM card, the user can initiate a core operation through the pre-installed business application (APP): sending a third request to the TSM platform. This third request can serve as a signal to trigger identity information recovery and can contain two types of key information: authentication data, i.e., the escrow password set by the user when authorizing key escrow, which can be used to verify the user's legitimacy and prevent impersonation; and security protection data, which, to prevent the request from being tampered with or eavesdropped on, requires the entire request message to be encrypted with the TSM platform's public key (ensuring that only the TSM platform can decrypt it) and signed with the APP's SM2 private key (ensuring that the request comes from the legitimate user's APP), forming a double security guarantee. Thus, this embodiment can prove to the TSM that the current requester is the legitimate holder of the original DID, providing a basis for the legitimacy of the identity for subsequent information recovery.

[0053] Specifically, after receiving the third request, the TSM platform needs to complete multi-layered verification. On one hand, it can verify the validity of the APP signature to confirm that the request has not been tampered with and comes from an authorized APP. On the other hand, it can verify the correctness of the escrow password to confirm that the requester is the user. After successful verification, the TSM platform can retrieve the DID and escrow information from its stored key escrow record table and send them to the terminal device. Among them, the DID is the user's distributed identity identifier generated and uploaded to the blockchain by the identity service platform in step 103, which can ensure consistency with the on-chain DID document; the escrow information is the escrow vector D corresponding to the master key pair reported in step 102, which can be used to recover the master key pair in the second SIM card later. Thus, the terminal device receives these two types of information through the APP, completes the data preparation for identity information recovery after SIM card replacement, and provides direct basis for writing information to the second SIM card in step 105.

[0054] In this way, the above steps achieve cross-hardware connectivity of user identity information in the SIM card replacement scenario: on the one hand, by using encrypted signatures and password verification, it is ensured that only legitimate users can initiate recovery requests, preventing the unauthorized acquisition of escrow information; on the other hand, by returning the original DID and escrow information through the TSM platform, the restriction of binding SIM card hardware and identity information is broken, providing key data for the subsequent recovery of the master key pair and DID in the second SIM card, solving the problem that SIM card replacement causes the on-chain DID to become invalid, and ensuring the continuity and validity of the user's distributed identity.

[0055] Step 105: Write the master key pair corresponding to the DID and the first information into the second SIM card.

[0056] Understandably, since the second SIM card is newly replaced hardware and does not initially carry the functional carrier required for key escrow, the TSM platform will first send preprocessing instructions to the terminal device to drive the second SIM card to complete the following: (1) Create a dedicated security domain, that is, to divide an independent hardware encryption area for the first hosted application, isolate other applications (such as communication applications) in the SIM card, and prevent unauthorized access across applications; (2) Configuring the initial security key can establish a trust link between the TSM and the second SIM card, ensuring the legitimacy of subsequent write and restore operations; (3) Download and install the first managed application. The key managed SIM card application (i.e., the first managed application) that is consistent with the first SIM card can be deployed to the second SIM card, so that it has the core capabilities of key generation, DID storage and managed information processing.

[0057] Thus, after preprocessing, the second SIM card has the basic functionality to receive DID and recover the master key pair.

[0058] In a specific embodiment of this application, after the TSM platform completes preprocessing of the second SIM card, it sends the DID to the first managed application of the second SIM card. When performing the write operation, two main rules must be met: First, association verification, meaning the first managed application will first verify whether the master key pair has been recovered (or is in a recoverable state). Only when the key base exists will writing the DID be allowed, avoiding an invalid state where there is an identity identifier but no corresponding key. Second, index recording, meaning that while writing the DID, the first managed application will internally establish a mapping relationship between the DID and the master key pair index. During subsequent distributed identity signing and verification, the corresponding master key pair can be quickly located through the DID, ensuring the smoothness of the identity authentication process. Therefore, after this step is completed, the user's distributed identity identifier is officially stored in the second SIM card hardware, corresponding to the on-chain DID document.

[0059] Subsequently, since the private key of the master key pair is never stored in plaintext in the TSM or terminal device, it needs to be derived through reverse engineering using escrow information. Specifically, the first escrow application on the second SIM card receives escrow information sent by the TSM platform, calls the built-in SM2 national cryptographic algorithm interface, and uses the escrow information as the core parameter to calculate and recover the master key pair that is completely identical to that of the first SIM card within the SIM card's hardware encryption area. The entire recovery process is completed within the SIM card hardware; the private key of the master key pair is always stored in the hardware encryption area and is never transmitted in plaintext, thus avoiding the risk of key leakage.

[0060] It should be noted that the above-mentioned writing does not involve transmitting and storing the plaintext key. Instead, it involves recovering the key through an algorithm and embedding it in the hardware. The final effect is equivalent to migrating the master key pair of the first SIM card to the second SIM card, ensuring that the keys of the two are completely identical. After recovery, the second SIM card has the same key signing and verification capabilities as the first SIM card. It can derive subkeys based on the master key pair to meet the identity authentication needs of multiple application scenarios.

[0061] Thus, this embodiment completely breaks the limitation of strong binding between SIM card hardware and DID / key. After a user changes their SIM card, there is no need to regenerate the DID or re-upload it to the blockchain. The existing DID document and historical transaction records on the blockchain remain valid, avoiding the problem of identity invalidation upon changing the card in existing technologies. In addition, the master key pair is recovered through an algorithm within the hardware, the private key is not leaked, and the DID and key are stored in the user's personal SIM card, which is in line with the core goal of distributed DID users to control their identity autonomously. At the same time, this embodiment does not require users to re-complete identity authentication, application authorization, and other processes. After changing the card, users can directly use their original distributed identity, improving the user experience while reducing the repetitive operating costs for identity service platforms and application providers.

[0062] Optionally, sending a first request to the Trusted Service Management (TSM) platform and receiving a first instruction from the TSM platform in response to the first request includes: In response to the operation instruction of the business APP, the first request is generated; wherein, the operation instruction includes a first signature, the first signature is obtained by signing the identification information of the target user with a first private key, the first private key is the private key in the first key pair corresponding to the business APP, and the target user is the user who logs into the business APP; Send the first request to the TSM platform, the first request carrying the first signature; The first instruction sent by the TSM platform in response to the first request is received, and the first instruction is used to instruct the first SIM card to install the first managed application under the first security domain.

[0063] In some embodiments, the terminal device can initiate a core operation via a business app: sending a second request to a pre-connected identity service platform. This second request can carry two types of key information: It should be noted that the aforementioned business APP can be the only terminal entry point for users to interact with distributed DID services (such as key escrow, DID management, card replacement and recovery, etc.). It has core functions such as receiving user operations, communicating with the TSM / identity service platform, and processing secure signatures. All user operations related to SIM card key escrow must be initiated through this APP.

[0064] The aforementioned first request may be a request sent to the TSM platform to apply for the installation of the first managed application (key managed SIM card application) on the first SIM card. It is the first instruction to start the key managed service, and its core purpose is to provide a hardware functional carrier (i.e., the first managed application) for subsequent master key pair generation and DID association.

[0065] In some embodiments, after the business APP responds to the operation command, it does not directly send a request. Instead, it needs to complete three steps of transformation: information collection, security processing, and format assembly, to ensure that the generated first request conforms to the interface specifications and security requirements of the TSM platform. Specifically, the first request may carry key information that allows the TSM platform to locate the user's SIM card and identify the application type. The APP will automatically collect or guide the user to supplement this information. Key information may include user identifier (i.e., the mobile phone number bound to the SIM card (used by the TSM platform to locate the user's first SIM card and ensure that the application is installed on the correct hardware), application identifier (i.e., the unique ID of the first hosted application (pre-assigned by the TSM platform and obtained by the APP upon access to ensure that the TSM platform knows the application to be installed), and may also include device identifier, i.e., the unique identification code of the terminal device (e.g., IMEI, to assist the TSM platform in verifying the legality of the device and preventing unauthorized installation across devices).

[0066] Subsequently, to prevent requests from being tampered with or impersonated, the app can encrypt and sign the collected parameters: it calls the built-in SM2 algorithm module and uses its own SM2 private key to sign the request parameters (phone number, application ID, etc.) to generate a first signature. This first signature is the core basis for the TSM platform to verify the legitimacy of the request, ensuring that the request comes from an authorized business app and is not forged by a malicious third party. Finally, the business app can assemble the original parameters and the first signature into a standardized first request message according to the TSM platform's preset interface protocol, ensuring that the TSM platform can correctly parse and execute it.

[0067] In some specific embodiments, the TSM platform can generate a first instruction after confirming the legitimacy of the first request through triple verification: Verification 1: Validity of the first signature. The TSM platform can call the SM2 algorithm module and use the pre-stored "first public key of the business APP" to verify the target user's identification information against the first signature. If the verification passes, it proves that the request comes from a legitimate business APP and that the identification information has not been tampered with; if the verification fails, the request is rejected.

[0068] Verification 2: Correlation of target user identification information. The TSM platform queries its own database to verify whether the target user's mobile phone number is bound to the ICCID of the first SIM card (ensuring that the request is directed to the user's currently used first SIM card), and at the same time confirms that the user is a legitimate user of the operator, avoiding sending instructions to invalid SIM cards.

[0069] Verification 3: Permissions of the first managed application. TSM confirms that the first managed application has completed the access filing (the identity provider applies for access to the SIM card application offline, and the TSM platform assigns security policies) and has the permission to install on the SIM card.

[0070] It should be noted that the aforementioned first security domain is a dedicated hardware encryption area created by the TSM platform for the first hosted application on the first SIM card. As a hardware security carrier, the SIM card supports the division of multiple independent security domains. Applications and data within each security domain are isolated from each other (e.g., isolating communication applications and other third-party applications within the SIM card), preventing the keys and DID information of the first hosted application from being accessed or tampered with by other applications.

[0071] In some embodiments, the first instruction may include three sets of core sub-instructions: sending an instruction to the first SIM card to create a first security domain, and configuring an initial security key for subsequent encrypted communication between the TSM and the first managed application; sending an instruction to the first SIM card to download the first managed application installation package, which is provided by the TSM platform to ensure its legitimate source; and sending an instruction to the first SIM card to install the first managed application within the first security domain, forcibly restricting the application installation path to prevent installation in insecure areas.

[0072] The TSM platform sends the first instruction to the terminal device via an over-the-air interface (such as OTA). After receiving the first instruction, the terminal device forwards it to the first SIM card. The first SIM card parses the instruction and sequentially executes operations such as creating a security domain, downloading the installation package, and installing the application, thus completing the deployment preparation of the first managed application.

[0073] Thus, this embodiment of the application can achieve anti-impersonation and anti-tampering, as well as hardware-level security isolation, by refining signature verification and security domain constraints. Specifically, the introduction of the first signature ensures that only authorized business apps and logged-in target users can initiate requests, preventing malicious third parties from forging requests. The design of the first security domain isolates the first managed application from other applications on the SIM card, providing a physically isolated secure environment for subsequent key storage and DID management.

[0074] Optionally, the first information further includes authorization information, and sending the first information to the TSM platform includes: In response to the authorization instruction from the business APP for the key escrow service, the authorization information of the key escrow service is obtained; The hosting information corresponding to the master key pair is generated through the first hosting application; Send the hosting information and the authorization information to the TSM platform.

[0075] In some embodiments, after the first escrow application generates the master key pair, the business app can display the key escrow service terms (such as escrow scope, TSM responsibilities, user rights, data usage, etc.) to the target user (a user already logged into the business app) through interactive methods such as pop-ups or page checkboxes, and prompt the user whether to authorize the key escrow service. When the user clicks the "agree to authorize" button (or completes an equivalent confirmation operation), the business app receives the key escrow service authorization instruction. This authorization instruction can be a trigger condition for subsequent processes, ensuring that the escrow behavior originates from the user's active choice.

[0076] In some embodiments, after the business app responds to the authorization command, it can automatically generate authorization information. Its core function is to prove that the user is aware of and agrees to the escrow service. Specifically, it includes the following elements: user identification, such as the target user's business app login account and the mobile phone number bound to the first SIM card; authorization statement, which can be structured text, clearly stating that the user agrees to the TSM platform escrowing the escrow information corresponding to the master key pair, or allows the key to be recovered through the escrow information when changing cards, etc.; timestamp, i.e., the precise time of the authorization operation, used to prevent the authorization information from being reused or tampered with; escrow password hash value, such as the escrow password set by the user during authorization, used for identity verification when restoring the key after changing cards. The business app can hash the password and store it in the authorization information to avoid plaintext transmission; second signature, such as the business app using the first private key to sign the above authorization information as a whole to generate a second signature, used by the TSM platform to verify the integrity and authenticity of the authorization information.

[0077] In a specific embodiment of this application, after user authorization, the business APP can send an instruction to the first managed application in the first SIM card to generate managed information. The first managed application, as a hardware-level security carrier, generates managed information based on the master key pair using the built-in SM2 algorithm (or KDF key derivation algorithm). The managed information can be a derived credential of the master key pair, possessing two main characteristics: first, it can only be generated from the master key pair and corresponds one-to-one with it; second, the master key pair can be derived in reverse (when changing SIM cards, the new SIM card can recover the original master key pair using the managed information).

[0078] In addition, the managed information can be generated by the first managed application within the hardware encryption area of ​​the SIM card, without being exposed in plaintext. It is transmitted directly through a secure channel (such as encrypted signaling between the SIM card and the TSM platform) to avoid being obtained by business apps or terminal devices, thus ensuring the security of the subsequent recovery process.

[0079] In other embodiments, the business application and the first managed application collaborate to assemble managed information and authorization information into a composite message. This composite message can be encrypted using the public key of the TSM platform, ensuring that only the TSM platform can decrypt it, preventing leakage of managed or authorized information during transmission. Furthermore, it is transmitted through a dedicated OTA channel or HTTPS encrypted channel to avoid man-in-the-middle attacks. Further, after receiving the composite message, the TSM platform can perform dual verification. Specifically, it can use the first public key of the business application to verify the second signature in the authorization information, confirming that the authorization information has not been tampered with and comes from a legitimate application. Simultaneously, it verifies the format of the managed password hash value, reserving a basis for subsequent recovery verification. After successful verification, the TSM platform associates the managed information with the user identifier and timestamp in the authorization information and stores them in the key managed record table, forming a complete link between the user, authorization record, and managed information. This allows for traceability of user authorization and provides a data foundation for subsequent SIM card replacement recovery.

[0080] Thus, this embodiment of the application transforms key escrow from a default technical behavior to a user-selectable behavior, fully aligning with the core principle of distributed DID user-controlled identity. Escrow information is stored in a bound manner with authorization information; the TSM platform only provides recovery services after verifying the validity of the authorization, preventing the misuse of escrow information and enhancing security.

[0081] Optionally, the step of sending a second request to the identity service platform pre-connected to the business application (APP) and receiving the DID sent by the identity service platform in response to the second request includes: Based on the private key in the first key pair corresponding to the business APP, the second information associated with the business APP is signed to obtain a second signature; wherein, the second information includes at least one of the authorization information, login information and target user identification information, and the target user is the user who logs into the business APP; Send the second request to the identity service platform; wherein the second request carries the second signature; Receive the DID generated by the identity service platform when the second signature verification is successful.

[0082] It should be noted that the second piece of information mentioned above is a core data set representing the user's identity and authorization status. It is used to prove to the identity service platform that the user applying for the DID has a legitimate identity and has completed the necessary authorization. Specifically, it includes: The authorization information, namely the user's authorization record for the "key escrow service" in the previous optional scheme (including user ID, authorization statement, timestamp, etc., see the previous optional scheme), is used to prove that the user has agreed to key escrow, which meets the premise of DID associated key; Login information, also known as login credentials information of the target user (user who has logged into the business APP), such as APP login session ID, biometric verification result (if enabled), etc., is used to prove that the user is currently in a legitimate login state and to prevent unlogged-in users from initiating requests; The target user's identification information may include the mobile phone number bound to the first SIM card, the user account ID of the business APP, etc., which are used by the identity service platform to locate the specific user applying for DID.

[0083] In some embodiments of this application, the business application can call the built-in national cryptographic SM2 algorithm module to perform the following operations to generate a second signature: First, the fields of the second information are concatenated into structured text in a preset order (such as user identifier, login information, and authorization information) to ensure that the identity service platform can parse them in the same order. Secondly, the private key in the first key pair corresponding to the business APP (i.e. the private key used to generate the first signature, which is matched with the public key exchanged in advance by the identity service platform) is used. Finally, the concatenated original text is encrypted and signed using the SM2 algorithm to generate a fixed-length second signature value. This signature value serves as the basis for the subsequent identity service platform to verify whether the request comes from a legitimate app and whether the data has been tampered with.

[0084] Subsequently, the business application can assemble the following information into a second request conforming to the identity service platform interface specification: the public key from the master key pair, second information (user identifier, login information, etc.), a second signature, a unique identifier for the business application (e.g., the application ID of the business application, to facilitate the identity service platform in matching the corresponding public key), a timestamp of the request (to prevent replay attacks), and a random number (to increase signature uniqueness). This is then transmitted via an HTTPS encrypted channel or a secure communication protocol specified by the identity service platform to ensure the request is not eavesdropped on during network transmission. Upon receiving the request, the identity service platform can first check the format integrity (e.g., whether it contains required fields such as the master key, public key, second signature, and user identifier); if the format verification fails, an error is returned directly.

[0085] Therefore, this embodiment of the application can generate a DID after verifying the legitimacy of the request by verifying the second signature. Specifically, the identity service platform calls the SM2 signature verification module to perform multiple verifications: it can use the first public key of the pre-stored business APP to concatenate the second information in the request into the original text in the order it was sent, and compare it with the second signature for verification. If the signature verification passes, it can prove that the request comes from an authorized business APP and that the second information has not been tampered with during transmission. At the same time, it can additionally verify the association between the user identifier in the second information and the master key to the public key (e.g., check whether the mobile phone number has been registered on the identity service platform) to ensure that the user's identity is genuine and valid.

[0086] After successful verification, the identity service platform performs the following operations: generates a DID, which is a unique DID identifier and a matching DID document (including the public key, identity service signature, and on-chain address) based on the public key (SM2 algorithm) in the master key pair; stores the DID document on the blockchain to ensure its public traceability and immutability; and returns the result by sending the generated DID identifier to the business APP through a secure channel, after which the business APP completes this step of the process.

[0087] Thus, this embodiment of the application can ensure, through the verification mechanism of the second signature and the first public key, that only authorized business apps can initiate DID requests, and that the request data has not been tampered with, thereby resolving the risk of malicious apps impersonating users to generate DIDs. Furthermore, it strengthens identity association, as the second information includes user identifiers, login information, etc., enabling the identity service platform to accurately associate DIDs with real users and avoid the generation of invalid DIDs without identity binding.

[0088] Optionally, after sending the DID to the TSM platform, the method further includes: Receive the third instruction sent by the TSM platform; If the first managed application has already generated a sub-key pair corresponding to the business APP, the DID is written to the first SIM card based on the third instruction; When the business APP initiates identity authentication, it sends the DID to the TSM platform and receives the identification information of the business APP sent by the TSM platform based on the managed record table; wherein, the managed record table is used to store the correspondence between the DID and the identification information of the business APP; Based on the identification information of the business APP, obtain the matching rules corresponding to the identification information of the business APP pre-written in the first managed application; The sub-key pair corresponding to the business APP is determined based on the matching rules.

[0089] In some embodiments of this application, after the business APP sends the DID to the TSM platform, the TSM platform can generate a third instruction. This third instruction can be an execution signal that triggers the DID to be written to the first SIM card. It can include: the DID identifier to be written, the security verification parameters of the write operation (such as the signature of the TSM platform to ensure that the instruction comes from a legitimate TSM), and the association index between the DID and the subkey pair (used for subsequent location of the subkey pair).

[0090] Specifically, after receiving the third instruction, the first managed application in the first SIM card can first perform a pre-verification to check whether a corresponding sub-key pair has been generated for the requesting business APP. If the sub-key pair has not been generated, writing to the DID is refused, and an error message is returned to prevent the DID from becoming disconnected from the key, ensuring that every identity identifier has a corresponding key. If the sub-key pair has been generated, the DID is written to a designated storage area within the first security domain, and a mapping relationship between the DID and the sub-key pair index is established. This mapping is used to quickly locate the required sub-key pair during subsequent identity authentication. Thus, this step strengthens the strong binding relationship between the DID and the key through sub-key pair existence verification, avoiding the storage of invalid identity identifiers.

[0091] In some embodiments, when a user accesses a service requiring distributed identity authentication using a business app (such as login to a financial app or authorization for a medical insurance service), the business app initiates an identity authentication request. This requires signing using a sub-key pair from the first SIM card (to prove the user possesses the corresponding private key), thus necessitating the determination of the sub-key pair corresponding to the app. Subsequently, the business app can send a query request containing the DID to the TSM platform, which performs the query based on the escrow record table. This escrow record table can store the DID identifier, key escrow information, identity service identifier, and may also contain the correspondence between the DID and the business app identifier information (such as the business app's unique ID and registration information at the time of access). After verifying the legitimacy of the request, the TSM platform can extract the business app identifier information bound to the DID from the escrow record table and return it to the business app. This ensures that the business app initiating authentication is a legitimate application associated with the DID, preventing other apps from abusing the DID.

[0092] In this embodiment, the matching rules can be maintained by the TSM platform and written into the SIM card application, ensuring that only valid business applications can use the SIM to generate and use the associated subkey pairs. These rules can be written to the first SIM card by the TSM platform during the installation of the first managed application (or during subsequent remote configuration), for example: direct mapping, i.e., "APP ID=xxx123" corresponds to "subkey pair index=001"; algorithmic mapping, i.e., dynamically calculating the corresponding index by associating the hash value (e.g., SM3 hash) of the business application's identification information with the subkey pair generation parameters; and permission mapping, which can include the range of subkey pairs that the business application can use. Subsequently, the business application can send its own identification information returned by the TSM platform to the first managed application of the first SIM card. The first managed application retrieves the corresponding matching rules from its internal secure storage area based on the identification information. This rule can be stored in the SIM card's hardware encryption area, accessible only to the first managed application, preventing tampering or leakage.

[0093] In some embodiments, subkey pairs can exist in two ways, and the matching rules must adapt to these two forms: First, stored type, where the first managed application generates the subkey pair and stores it on the SIM card (suitable for high-frequency use scenarios), and the matching rules directly return the index of the stored subkey pair; Second, dynamically generated type, where the subkey pair is not stored, but dynamically calculated each time it is used based on the master key pair, APP identification information, and matching rules. The matching rules include parameters of the generation algorithm (such as salt value and number of iterations). The first managed application can execute based on the matching rules: If it is stored type, the corresponding subkey pair can be retrieved from the secure storage area according to the index returned by the rules (the private key is still stored in the hardware and not exposed externally); if it is dynamically generated type, the built-in SM2 algorithm can be called, using the master key pair and APP identification information as input, to calculate and generate the subkey pair according to the parameters in the rules, ensuring that the calculation results are consistent each time. Finally, the first managed application can use the determined subkey pair to sign the identity authentication request of the business APP (such as signing the authentication challenge information) to complete distributed identity verification. During this process, the private key of the subkey pair is always operated within the SIM card and is not disclosed to the business APP or terminal device.

[0094] In this way, the embodiments of this application can ensure that different business apps can only use their corresponding sub-key pairs by associating matching rules with sub-key pairs, avoiding key mixing, improving key security in multiple scenarios, and solving the bottleneck of limited SIM card memory by combining the precise positioning of matching rules. In addition, by linking DID, APP identifier, matching rules, and sub-key pairs, it is ensured that the key used for identity authentication is strictly bound to DID and APP, avoiding the risk of key mismatch during the authentication process.

[0095] Optionally, when the terminal device replaces the first SIM card with the second SIM card, sending a third request to the TSM platform includes: When the terminal device replaces the first SIM card with the second SIM card, the authorization information is encrypted based on the second public key, and the encrypted authorization information is signed based on the first private key to obtain a third signature; Send the third request to the TSM platform, the third request including the third signature to be verified; The second public key is the public key that the TSM platform pre-sent to the terminal device, and the first private key is the private key in the first key pair corresponding to the business APP.

[0096] It should be noted that the second public key mentioned above can be the SM2 public key of the TSM platform (pre-sent to the terminal device and stored via a secure channel), and its corresponding private key is held only by the TSM platform. This private key is used to encrypt sensitive information, ensuring that only the TSM platform can decrypt it, thus guaranteeing the confidentiality of information transmission. The authorization information mentioned above can be an authorization record generated by the user during the key escrow stage (including user identifier, escrow statement, escrow password hash value, etc.), serving as the core credential for the user's agreement to the card replacement and recovery key, proving that the recovery operation conforms to the user's true intentions. The first private key mentioned above can be the SM2 private key corresponding to the business APP, whose public key has been pre-synchronized to the TSM platform. This is used to sign the encrypted information, proving that the request comes from a legitimate business APP, preventing the request from being tampered with or forged.

[0097] In some specific embodiments, after the terminal device is replaced with a second SIM card, the service APP triggers the recovery key and DID operation process, which specifically executes as follows: (1) The authorization information is encrypted with the second public key. The business APP can call the national cryptographic SM2 encryption module to encrypt the authorization information as plaintext using the second public key to generate the encrypted authorization information. The authorization information may contain sensitive data such as user identifier and escrow password hash. After encryption, only the TSM platform can decrypt it with its own private key to prevent it from being stolen by terminal devices, network nodes or malicious third parties during transmission and to ensure the confidentiality of information.

[0098] (2) Sign the encrypted authorization information using the first private key to generate a third signature. The business APP calls the SM2 signature module, uses the encrypted authorization information as the signature text, and signs it using the first private key to generate a third signature. Thus, the TSM platform can verify the signature using the APP's first public key to confirm that the encrypted authorization information has not been tampered with during transmission. In addition, it can also prove that the request comes from an authorized business APP (not a maliciously forged third-party application).

[0099] Specifically, the business app can assemble the following information into a third request conforming to the TSM platform interface specification: a third signature (for signature verification), encrypted authorization information (for TSM decryption verification), the target user's identification information (such as the mobile phone number bound to the replaced second SIM card, used by the TSM platform to locate the user's managed record), a request timestamp (to prevent replay attacks and avoid the same request being reused), and device and card information (e.g., the terminal device's device identifier, the second SIM card's hardware identifier, etc.). Among these, the device and card information can assist the TSM platform in verifying the authenticity of the card replacement operation and confirming that a new SIM card is currently being used.

[0100] Meanwhile, the TSM platform can receive third-party requests through a secure channel (such as an encrypted OTA channel from a carrier) and first perform format and integrity checks: checking whether the request contains required fields such as a third signature, encrypted authorization information, and user identifier; and verifying the validity of the timestamp (e.g., determining whether it is within a preset valid time window to prevent expired requests). If the pre-verification fails, an error response is returned directly; if it passes, the process proceeds to the next core verification stage.

[0101] In this way, the embodiments of this application can achieve confidentiality protection. The authorization information is encrypted with the TSM platform's public key and can only be decrypted by the TSM platform, avoiding the leakage of sensitive data. At the same time, the third signature can ensure that the request comes from a legitimate APP and that the information has not been tampered with, thus solving the risk of identity theft in card replacement scenarios. In addition, initiating the request based on the user's pre-authorized information complies with the distributed DID principle of user self-control over identity recovery, building a complete security defense for key recovery requests in card replacement scenarios.

[0102] Optionally, receiving the DID and the hosting information sent by the TSM platform in response to the third request includes: If the third signature verification is successful, a second instruction sent by the TSM platform in response to the third request is received, the second instruction including the DID and the first information; After receiving the DID and the hosting information sent by the TSM platform in response to the third request, the method further includes: Based on the second instruction, a second managed application is installed within the second security domain of the second SIM card; The second instruction carries the second security domain, and the second managed application is used to write the DID and the master key pair into the second SIM card.

[0103] In some embodiments, the TSM platform can perform triple verification on the third request (including a third signature) sent by the terminal device to confirm that: ① the request comes from a legitimate business APP; ② the authorization information is authentic and valid, i.e., the user agrees to the restoration; ③ the SIM card replacement operation conforms to the user's identity association, i.e., the second SIM card is bound to the user. After successful verification, the TSM platform generates and sends a second instruction, which is the basis for driving the second SIM card to complete subsequent operations.

[0104] It should be noted that the second instruction is a composite instruction that may contain three types of key information, all of which are signed and encrypted via the TSM platform's private key to ensure the integrity and confidentiality of the instruction. Specifically, the second instruction may include the DID, the first information, security domain configuration parameters (such as the second security domain (which is the exclusive hardware encryption area identifier assigned by the TSM platform to the second managed application in the second SIM card, such as the security domain ID and access control policy), which has the same function as the first security domain of the first SIM card and is used to isolate other applications in the second SIM card and ensure the security of the recovered key and DID), and application installation instructions (which may include the installation package index of the second managed application (pointing to the application stored on the TSM platform), the installation path (forced to be within the second security domain), and the initial security key (used for subsequent encrypted communication between the TSM and the second managed application), etc.

[0105] In some embodiments, the second managed application and the first managed application can be key management applications with the same function and version, distinguished only by their different names. Their core functions include: receiving and storing DID identifiers, recovering master key pairs based on managed information, generating sub-key pairs associated with the business application (supporting subsequent identity authentication), and performing secure communication with the TSM platform (e.g., encrypted data transmission, command verification).

[0106] In a specific embodiment of this application, after receiving the second instruction, the terminal device forwards it to the second SIM card, and the second SIM card performs the following operations according to the instruction: (1) Create a second security domain. The second security domain configuration parameters in the second SIM card parsing command divide an independent encrypted storage and operation area at the hardware level. Among them, through hardware-level access control, the second security domain can be restricted to being accessed only by the second managed application, completely isolated from the communication application in the second SIM card and other third-party applications, preventing unauthorized access to the recovered key and DID. Initial key configuration can write the initial security key in the command into the root key area of ​​the second security domain, which serves as the trust basis for subsequent interactions between the TSM platform and the second managed application. That is, all communication must be encrypted and verified through this key.

[0107] (2) Download and install the second managed application. The second SIM card downloads the installer of the second managed application through the secure channel specified by the TSM platform, based on the installation package index in the instruction, and deploys the application in the second security domain strictly according to the installation path constraints. It should be noted that before installing the second managed application, the second SIM card can use the public key of the TSM platform to verify the signature of the installation package to ensure that the application comes from the TSM platform and has not been tampered with or replaced. In addition, it can also confirm that the application supports core functions such as recovering the master key pair based on the managed information and writing the DID (aligned with the functions of the first managed application), avoiding recovery failure due to application version incompatibility.

[0108] (3) Status feedback after installation: After the second managed application is successfully installed, it returns an installation success response (including application running status and second security domain identifier) ​​to the TSM platform. The TSM platform updates the user's key management record table, associates the ICCID and second security domain identifier of the second SIM card with the DID, and completes the filing of the functional carrier after the card replacement.

[0109] Thus, this embodiment of the application can construct a secure operating environment on the second SIM card that is completely identical to that of the first SIM card through the deployment of the second security domain and the second managed application, ensuring hardware-level security for key recovery and DID storage. Simultaneously, the installation of the second managed application provides the necessary functional carrier for subsequent DID writing and master key pair recovery, ensuring that users can continue to use the distributed identity service after SIM card replacement, thus solving the technical problem of functional failure upon SIM card replacement.

[0110] Please see Figure 2 The second flowchart of a key escrow method based on a SIM card in this application embodiment specifically includes the following steps: Step 201: The terminal device sends a first request to the TSM platform; The terminal device sends an initial request to the TSM platform corresponding to its business app. This request contains a "first signature" used to verify the legitimacy and identity of the request.

[0111] Step 202: The TSM platform returns the first instruction to the terminal device; After verifying the first signature, the TSM platform returns an instruction to the terminal device to authorize and instruct the terminal device to install the specified managed application in the security domain of its current SIM card (first SIM card).

[0112] Step 203: Internal operation of the terminal device: Install the first managed application; Therefore, after receiving instructions from the TSM platform, the terminal device installs a program called the first managed application on its first SIM card, thereby creating a secure trusted execution environment that can be used to generate and store keys.

[0113] Step 204: Internal operation of the terminal device: The first managed application generates a master key pair; After the first managed application is successfully installed, an asymmetric cryptographic key pair, namely the master key pair (containing a public key and a private key), is generated inside the SIM card. This generates the root key for the entire managed scheme. The private key is always securely stored inside the SIM card and will not be leaked.

[0114] Step 205: The terminal device sends the first message to the TSM platform; Specifically, the terminal device can send the "escrow information" of the master key pair (which may include the public key, key identifier, etc., but not the private key) and the user's "authorization information" for the service to the TSM platform. This allows information such as the public key to be entrusted to the TSM platform, preparing for subsequent key recovery.

[0115] Step 206: The terminal device sends a second request to the identity service platform; The terminal device sends a request to the identity service platform. This request contains the "public key" from the master key pair and a "second signature" used for verification. Thus, this application can request the identity service platform to create a DID for the user based on the public key.

[0116] Step 207: The identity service platform returns the DID to the terminal device; In this process, after verifying the second signature, the identity service platform uses the received public key to generate a unique DID for the terminal device and returns it to the terminal device. Thus, this embodiment of the application can bind a user's DID to their hardware security key (master key pair).

[0117] Step 208: The terminal device sends the DID to the TSM platform; Specifically, the terminal device can send the DID obtained from the identity service platform to the TSM platform so that the TSM platform can associate the DID with previously received managed information.

[0118] Step 209: Internal operations of the TSM platform, storing association relationships; The TSM platform establishes and stores the mapping between DIDs and business application identifiers in its database. It completes managed registration so that, when needed in the future, the corresponding user and application information can be retrieved via the DID, thereby enabling key recovery.

[0119] Step 210: The terminal device sends a third request to the TSM platform; Specifically, when a terminal device replaces its SIM card (second SIM card), it can send a recovery request to the TSM platform. This request includes a third-party signature used to verify the user's identity and the legitimacy of the request. This allows the user to prove their identity to the TSM platform and request the recovery of previously held keys and DIDs.

[0120] Step 211: The TSM platform returns a second instruction to the terminal device; After the TSM platform verifies the third signature, it sends a command to the terminal device. This command contains the previously hosted "DID" and "hosted information" (mainly the public key of the master key, etc.). It then authorizes the recovery process and provides the critical data required for recovery.

[0121] Step 212: Internal operation of the terminal device: Install the second managed application on the second SIM card; In this process, the terminal device installs a managed application (second managed application) on the new SIM card (second SIM card) according to the instructions of the TSM platform, thereby creating the same security environment on the new SIM card as before.

[0122] Step 213: Internal operation of the terminal device: Write the DID and master key pair; Specifically, the second managed application writes the DID sent back by the TSM platform and the master key pair recovered based on the managed information (with the assistance of TSM) into the new SIM card. Thus, this embodiment of the application completes the secure migration of keys and identity from the old SIM card to the new SIM card, allowing users to continue using their original identity and services without re-registering.

[0123] Please see Figure 3 This application provides a key escrow method based on a SIM card, applied to a TSM platform. The method includes: Step 301: Receive the first request sent by the terminal device; Step 302: In response to the first request, send a first instruction to the terminal device, the first instruction being used to instruct the terminal device to install a first managed application on the first SIM card; Step 303: Receive first information sent by the terminal device, the first information including managed information corresponding to the master key pair, the master key pair being a key pair generated by the first managed application; Step 304: Receive the DID sent by the terminal device, wherein the DID is generated by the identity service platform based on the public key in the master key pair; Step 305: Receive the third request sent by the terminal device, and in response to the third request, send the DID and the hosting information to the terminal device.

[0124] Optionally, before the receiving terminal device sends the first request, the method further includes: The system receives a fourth request from the operation server of the business app; wherein the business app is an app pre-deployed on the terminal device, and the fourth request carries the identification information of the business app. If the operating server is connected to the identity service platform, in response to the fourth request, perform at least one of the following: Configure the third security domain and third key pair corresponding to the identity service platform, and send the third security domain and third key pair to the identity service platform; The identification information of the business APP is entered into the whitelist sequence of the TSM platform; Configure a service interface, which is used to provide access services for the business APP.

[0125] Optionally, after receiving the DID sent by the terminal device, the method further includes any one or more of the following: The DID is stored in a pre-built managed record table, which is used to store the correspondence between the DID and the identification information of the business APP; If the first managed application has generated a sub-key pair corresponding to the business APP, a third instruction is sent to the terminal device, the third instruction being used to instruct the DID to be written to the first SIM card; When the business APP initiates identity authentication, it receives the DID sent by the terminal device and returns the identification information of the business APP corresponding to the DID in the managed record table to the terminal device.

[0126] Optionally, in response to the third request, sending the DID and the hosting information to the terminal device includes: In response to the third request, the third signature carried in the third request is verified based on the second private key in the second key pair corresponding to the TSM platform and the first private key in the first key pair corresponding to the business APP. If the third signature verification is successful, a second instruction is sent to the terminal device; The second instruction carries the DID and the managed information, and also carries a second security domain.

[0127] The embodiments described above provide a SIM card-based key escrow and recovery mechanism led by the TSM platform. Its core implementation process can be divided into three stages: The first phase, the initial configuration, involves the TSM platform receiving access requests (the fourth request) from business app operators. This is done by configuring security domains, key pairs, whitelists, and service interfaces to prepare for subsequent key hosting services.

[0128] The second phase involves key escrow and registration: The TSM platform receives the initial request (first request) from the terminal device and authorizes it to install a secure escrow application on the SIM card. After the escrow application generates a master key pair, the TSM platform receives and saves its escrow information. The TSM platform also receives the user's decentralized identifier (DID) generated by the identity service platform and bound to the public key, and establishes a mapping between the DID and the business application.

[0129] The third stage, key recovery: When a user replaces their SIM card, the TSM platform receives a recovery request (third request). The platform uses its own private key and the private key of the business app to double-verify the signature in the request (third signature) to ensure the request's legitimacy. After successful verification, the TSM platform securely sends the previously hosted DID and key information to the new SIM card, completing the key recovery.

[0130] Thus, in this embodiment, the master private key is always generated and stored within the secure domain of the SIM card and is never directly transmitted, fundamentally avoiding the risk of key leakage. When recovering the key, simultaneous signature verification by both the TSM platform and the business app is required, greatly enhancing the security of the recovery process and preventing unauthorized requests. Utilizing the inherent security chip characteristics of the SIM card, a higher level of key protection than software storage is provided. Furthermore, this embodiment also improves user experience and convenience. After changing a mobile phone or SIM card, users can automatically recover all key-based digital identities and business permissions without re-registering an account or undergoing complex identity verification processes, achieving seamless migration. Moreover, through whitelist and service interface configuration, the TSM platform can easily provide unified key escrow services for multiple different business apps. As a centralized escrow provider, the TSM platform can efficiently manage all users' key escrow records (DID-App mapping relationship), facilitating auditing and service.

[0131] As can be seen, the above embodiments of this application combine the hardware security features of SIM cards with the DID identity identifier of the blockchain era. By using the TSM platform as a trusted intermediary, it solves the pain point of key and identity recovery when users change devices while ensuring the highest level of security, and provides a reliable infrastructure for a wide range of digital identity authentication scenarios.

[0132] Please see Figure 4 This application provides a key escrow method based on a SIM card, applied to an identity service platform. The method includes: Step 401: Receive a second request sent by the terminal device. The second request carries the public key in the master key pair. The master key pair is a key pair generated based on the first managed application. The first managed application is an application installed on the first SIM card in the terminal device. Step 402: In response to the second request, generate the DID corresponding to the terminal device based on the public key in the master key pair; Step 403: Send the DID to the terminal device.

[0133] Optionally, before receiving the second request sent by the terminal device, the method further includes: Receive a fifth request sent by the operation server of the business APP; wherein, the business APP is an APP pre-deployed on the terminal device; In response to the fifth request, the third public key of the third key pair is sent to the operation server. The third key pair is a key pair pre-configured by the identity service platform. Receive the first public key sent by the operation server, wherein the first public key is the public key in the first key pair corresponding to the business APP.

[0134] Optionally, in response to the second request, generating the DID corresponding to the terminal device based on the public key in the master key pair includes: In response to the second request, the second signature carried in the second request is verified based on the first public key; If the second signature verification passes, the DID is generated based on the public key in the master key pair.

[0135] In the above embodiments of this application, the core role of the identity service platform in the SIM card-based key escrow system is defined, namely, issuing trusted digital identities, or DIDs. The implementation process is clear and direct, including: Before receiving a terminal request, the identity service platform first connects with the business app's operation server. Both parties establish a secure communication and trust relationship by exchanging public keys (the platform's third public key and the business app's first public key), laying the foundation for subsequent verification of the request's legitimacy. The platform receives a second request from the terminal device, the core of which is the public key in the master key pair generated within the SIM card's security domain. The platform uses the first public key previously obtained from the business app to verify the second signature carried in the request. This step ensures that the request is initiated by a legitimate and authorized business app, and not a malicious request. After successful verification, the platform uses the public key provided by the terminal as the generation material to create a unique, decentralized identity identifier (DID) for the terminal device or user. Finally, the platform sends the DID to the terminal device to complete identity registration.

[0136] As can be seen, in this embodiment, the DID is directly bound to an immutable public key generated within the secure element of the terminal SIM card, ensuring that the foundation of digital identity comes from the highest level of hardware trust root. By verifying the signature (second signature) of the business APP, it is ensured that the request to issue the DID comes from a legitimate and authorized application, effectively preventing attacks that maliciously generate DIDs in bulk, and guaranteeing the credibility of DID issuance from the source. In addition, a decentralized identity paradigm is implemented. This process perfectly embodies the core idea of ​​decentralized identity: the user's DID is controlled by the user (whose key is generated on their own device) and issued by a trusted third party (identity service platform), rather than being directly allocated by a centralized application service provider.

[0137] Please refer to Figure 5 , Figure 5 This is one of the structural schematic diagrams of a SIM card-based key escrow device according to an embodiment of this application. The SIM card-based key escrow device 500 is applied to a terminal device, and the device specifically includes: The first sending module 501 is used to send a first request to the Trusted Service Management (TSM) platform, receive a first instruction sent by the TSM platform in response to the first request, and install a first managed application on the first SIM card in the terminal device based on the first instruction. The first acquisition module 502 is used to acquire the master key pair generated based on the first hosting application and send first information to the TSM platform, the first information including hosting information corresponding to the master key pair; The second sending module 503 is used to send a second request to the identity service platform that the business application APP has pre-accessed, receive the DID sent by the identity service platform in response to the second request, and send the DID to the TSM platform; the second request carries the public key in the master key pair, and the DID is generated by the identity service platform based on the public key in the master key pair. The third sending module 504 is used to send a third request to the TSM platform when the terminal device replaces the first SIM card with the second SIM card, and to receive the DID and the managed information sent by the TSM platform in response to the third request. The first writing module 505 is used to write the master key pair corresponding to the DID and the first information into the second SIM card.

[0138] Optionally, the first sending module 501 includes: The first generation unit is configured to generate the first request in response to the operation instruction of the business APP; wherein the operation instruction includes a first signature, the first signature is obtained by signing the identification information of the target user with a first private key, the first private key is the private key in the first key pair corresponding to the business APP, and the target user is the user who logs into the business APP. The first sending unit is configured to send the first request to the TSM platform, wherein the first request carries the first signature; The first receiving unit is configured to receive the first instruction sent by the TSM platform in response to the first request, wherein the first instruction is configured to instruct the first SIM card to install the first managed application under the first security domain.

[0139] Optionally, the first acquisition module 502 includes: The first acquisition unit is used to respond to the authorization instruction of the business APP for the key escrow service and acquire the authorization information of the key escrow service; The second generation unit is used to generate the hosting information corresponding to the master key pair through the first hosting application; The second sending unit is used to send the hosting information and the authorization information to the TSM platform.

[0140] Optionally, the second transmitting module 503 is used to: Based on the private key in the first key pair corresponding to the business APP, the second information associated with the business APP is signed to obtain a second signature; wherein, the second information includes at least one of the authorization information, login information and target user identification information, and the target user is the user who logs into the business APP; Send the second request to the identity service platform; wherein the second request carries the second signature; Receive the DID generated by the identity service platform when the second signature verification is successful.

[0141] Optionally, the SIM card-based key escrow device 500 is further configured to: Receive the third instruction sent by the TSM platform; If the first managed application has already generated a sub-key pair corresponding to the business APP, the DID is written to the first SIM card based on the third instruction; When the business APP initiates identity authentication, it sends the DID to the TSM platform and receives the identification information of the business APP sent by the TSM platform based on the managed record table; wherein, the managed record table is used to store the correspondence between the DID and the identification information of the business APP; Based on the identification information of the business APP, obtain the matching rules corresponding to the identification information of the business APP pre-written in the first managed application; The sub-key pair corresponding to the business APP is determined based on the matching rules.

[0142] Optionally, the third sending module 504 is used for: When the terminal device replaces the first SIM card with the second SIM card, the authorization information is encrypted based on the second public key, and the encrypted authorization information is signed based on the first private key to obtain a third signature; Send the third request to the TSM platform, the third request including the third signature to be verified; The second public key is the public key that the TSM platform pre-sent to the terminal device, and the first private key is the private key in the first key pair corresponding to the business APP.

[0143] Optionally, the third sending module 504 is used for: If the third signature verification is successful, a second instruction sent by the TSM platform in response to the third request is received, the second instruction including the DID and the first information; After receiving the DID and the hosting information sent by the TSM platform in response to the third request, the method further includes: Based on the second instruction, a second managed application is installed within the second security domain of the second SIM card; The second instruction carries the second security domain, and the second managed application is used to write the DID and the master key pair into the second SIM card.

[0144] The SIM card-based key escrow device 500 provided in this application embodiment can perform the above-described... Figure 1 The method embodiments shown are similar in principle and technical effect, and will not be described again here.

[0145] Please refer to Figure 6 , Figure 6 This is a second schematic diagram of a SIM card-based key escrow device according to an embodiment of this application. The SIM card-based key escrow device 600 is applied to a TSM platform, and the device specifically includes: The first receiving module 601 is used to receive a first request sent by the terminal device; The fourth sending module 602 is used to send a first instruction to the terminal device in response to the first request, wherein the first instruction is used to instruct the terminal device to install a first managed application on the first SIM card; The second receiving module 603 is used to receive first information sent by the terminal device, the first information including managed information corresponding to the master key pair, the master key pair being a key pair generated by the first managed application; The third receiving module 604 is used to receive the DID sent by the terminal device, wherein the DID is generated by the identity service platform based on the public key in the master key pair; The fourth receiving module 605 is used to receive the third request sent by the terminal device, and in response to the third request, send the DID and the hosting information to the terminal device.

[0146] Optionally, the SIM card-based key escrow device 600 is further configured to: The system receives a fourth request from the operation server of the business app; wherein the business app is an app pre-deployed on the terminal device, and the fourth request carries the identification information of the business app. If the operating server is connected to the identity service platform, in response to the fourth request, perform at least one of the following: Configure the third security domain and third key pair corresponding to the identity service platform, and send the third security domain and third key pair to the identity service platform; The identification information of the business APP is entered into the whitelist sequence of the TSM platform; Configure a service interface, which is used to provide access services for the business APP.

[0147] Optionally, the SIM card-based key escrow device 600 is further used for any one or more of the following: The DID is stored in a pre-built managed record table, which is used to store the correspondence between the DID and the identification information of the business APP; If the first managed application has generated a sub-key pair corresponding to the business APP, a third instruction is sent to the terminal device, the third instruction being used to instruct the DID to be written to the first SIM card; When the business APP initiates identity authentication, it receives the DID sent by the terminal device and returns the identification information of the business APP corresponding to the DID in the managed record table to the terminal device.

[0148] Optionally, the fourth receiving module 605 is used for: In response to the third request, the third signature carried in the third request is verified based on the second private key in the second key pair corresponding to the TSM platform and the first private key in the first key pair corresponding to the business APP. If the third signature verification is successful, a second instruction is sent to the terminal device; The second instruction carries the DID and the managed information, and also carries a second security domain.

[0149] The SIM card-based key escrow device 600 provided in this application embodiment can perform the above-described... Figure 3 The method embodiments shown are similar in principle and technical effect, and will not be described again here.

[0150] Please refer to Figure 7 , Figure 7 This is the third schematic diagram of a SIM card-based key escrow device in this application embodiment. The SIM card-based key escrow device 700 is applied to an identity service platform, and the device specifically includes: The fifth receiving module 701 is used to receive a second request sent by the terminal device. The second request carries the public key in the master key pair. The master key pair is a key pair generated based on the first managed application. The first managed application is an application installed on the first SIM card in the terminal device. The first generation module 702 is used to generate the DID corresponding to the terminal device based on the public key in the master key pair in response to the second request. The fifth sending module 703 is used to send the DID to the terminal device.

[0151] Optionally, the SIM card-based key escrow device 700 is further configured to: Receive a fifth request sent by the operation server of the business APP; wherein, the business APP is an APP pre-deployed on the terminal device; In response to the fifth request, the third public key of the third key pair is sent to the operation server. The third key pair is a key pair pre-configured by the identity service platform. Receive the first public key sent by the operation server, wherein the first public key is the public key in the first key pair corresponding to the business APP.

[0152] Optionally, the first generation module 702 is used for: In response to the second request, the second signature carried in the second request is verified based on the first public key; If the second signature verification passes, the DID is generated based on the public key in the master key pair.

[0153] The SIM card-based key escrow device 700 provided in this application embodiment can perform the above-described... Figure 4 The method embodiments shown are similar in principle and technical effect, and will not be described again here.

[0154] This application also provides an electronic device. Since the principle by which this electronic device solves the problem is similar to the SIM card-based key escrow method in this application, the implementation of this electronic device can be found elsewhere. Figure 1 The implementation of the method shown will not be repeated here. Figure 8 As shown, the electronic device according to an embodiment of this application includes: a processor 810, configured to read a program from a memory 820 and execute the following processes: The transceiver 830 sends a first request to the Trusted Service Management (TSM) platform, receives a first instruction from the TSM platform in response to the first request, and installs a first managed application on the first SIM card in the terminal device based on the first instruction. Obtain the master key pair generated based on the first managed application, and send the first information to the TSM platform through transceiver 830. The first information includes managed information corresponding to the master key pair. The transceiver 830 sends a second request to the identity service platform that is pre-connected to the business application APP, receives the DID sent by the identity service platform in response to the second request, and sends the DID to the TSM platform; the second request carries the public key in the master key pair, and the DID is generated by the identity service platform based on the public key in the master key pair. When the terminal device replaces the first SIM card with the second SIM card, it sends a third request to the TSM platform through the transceiver 830 and receives the DID and the managed information sent by the TSM platform in response to the third request. Write the master key pair corresponding to the DID and the first information into the second SIM card.

[0155] Among them, Figure 8 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits of one or more processors represented by processor 810 and memory represented by memory 820 together. The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides the interface.

[0156] Optionally, the processor 810 is also used to read the program from the memory 820 and perform the following steps: In response to the operation instruction of the business APP, the first request is generated; wherein, the operation instruction includes a first signature, the first signature is obtained by signing the identification information of the target user with a first private key, the first private key is the private key in the first key pair corresponding to the business APP, and the target user is the user who logs into the business APP; The first request is sent to the TSM platform via transceiver 830, and the first request carries the first signature. The transceiver 830 receives the first instruction sent by the TSM platform in response to the first request, the first instruction being used to instruct the first SIM card to install the first managed application under the first security domain.

[0157] Optionally, the processor 810 is also used to read the program from the memory 820 and perform the following steps: In response to the authorization instruction from the business APP for the key escrow service, the authorization information of the key escrow service is obtained; The hosting information corresponding to the master key pair is generated through the first hosting application; The hosting information and the authorization information are sent to the TSM platform via transceiver 830.

[0158] Optionally, the processor 810 is also used to read the program from the memory 820 and perform the following steps: Based on the private key in the first key pair corresponding to the business APP, the second information associated with the business APP is signed to obtain a second signature; wherein, the second information includes at least one of the authorization information, login information and target user identification information, and the target user is the user who logs into the business APP; The second request is sent to the identity service platform via transceiver 830; wherein the second request carries the second signature; The transceiver 830 receives the DID generated by the identity service platform when the second signature verification is successful.

[0159] Optionally, the processor 810 is also used to read the program in the memory 820 and perform the following steps: The transceiver 830 receives the third instruction sent by the TSM platform; If the first managed application has already generated a sub-key pair corresponding to the business APP, the DID is written to the first SIM card based on the third instruction; When the business APP initiates identity authentication, it sends the DID to the TSM platform through transceiver 830 and receives the identification information of the business APP sent by the TSM platform based on the managed record table; wherein, the managed record table is used to store the correspondence between the DID and the identification information of the business APP; Based on the identification information of the business APP, obtain the matching rules corresponding to the identification information of the business APP pre-written in the first managed application; The sub-key pair corresponding to the business APP is determined based on the matching rules.

[0160] Optionally, the processor 810 is also used to read the program from the memory 820 and perform the following steps: When the terminal device replaces the first SIM card with the second SIM card, the authorization information is encrypted based on the second public key, and the encrypted authorization information is signed based on the first private key to obtain a third signature; The third request, which includes the third signature to be verified, is sent to the TSM platform via transceiver 830. The second public key is the public key that the TSM platform pre-sent to the terminal device, and the first private key is the private key in the first key pair corresponding to the business APP.

[0161] Optionally, the processor 810 is also used to read the program from the memory 820 and perform the following steps: If the third signature verification is successful, the transceiver 830 receives a second instruction sent by the TSM platform in response to the third request, the second instruction including the DID and the first information; After receiving the DID and the hosting information sent by the TSM platform in response to the third request, the method further includes: Based on the second instruction, a second managed application is installed within the second security domain of the second SIM card; The second instruction carries the second security domain, and the second managed application is used to write the DID and the master key pair into the second SIM card.

[0162] The electronic device 800 provided in this application embodiment can perform the above-described... Figure 1 The method embodiments shown are similar in principle and technical effect, and will not be described again here.

[0163] This application also provides an electronic device. Since the principle by which this electronic device solves the problem is similar to the SIM card-based key escrow method in this application, the implementation of this electronic device can be found elsewhere. Figure 3 The implementation of the method shown will not be repeated here. Figure 9 As shown, the electronic device according to an embodiment of this application includes: a processor 910, configured to read a program from a memory 920 and execute the following processes: The transceiver 930 receives the first request sent by the terminal device; In response to the first request, a first instruction is sent to the terminal device via transceiver 920, the first instruction being used to instruct the terminal device to install a first managed application on the first SIM card; The transceiver 930 receives first information sent by the terminal device, the first information including managed information corresponding to the master key pair, the master key pair being a key pair generated by the first managed application; The transceiver 930 receives the DID sent by the terminal device, wherein the DID is generated by the identity service platform based on the public key in the master key pair; The transceiver 930 receives the third request sent by the terminal device and, in response to the third request, sends the DID and the hosting information to the terminal device.

[0164] Among them, Figure 9 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits of one or more processors represented by processor 910 and memory represented by memory 920 together. The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides the interface.

[0165] Optionally, the processor 910 is also used to read the program from the memory 920 and perform the following steps: The transceiver 930 receives a fourth request sent by the operation server of the business APP; wherein the business APP is an APP pre-deployed on the terminal device, and the fourth request carries the identification information of the business APP; If the operating server is connected to the identity service platform, in response to the fourth request, perform at least one of the following: Configure the third security domain and third key pair corresponding to the identity service platform, and send the third security domain and third key pair to the identity service platform through transceiver 930; The identification information of the business APP is entered into the whitelist sequence of the TSM platform; Configure a service interface, which is used to provide access services for the business APP.

[0166] Optionally, the processor 910 is also used to read programs from the memory 920 and execute any one or more of the following: The DID is stored in a pre-built managed record table, which is used to store the correspondence between the DID and the identification information of the business APP; If the first managed application has generated a sub-key pair corresponding to the business APP, a third instruction is sent to the terminal device through the transceiver 930. The third instruction is used to instruct the DID to be written into the first SIM card. When the business APP initiates identity authentication, the transceiver 930 receives the DID sent by the terminal device and returns the identification information of the business APP corresponding to the DID in the managed record table to the terminal device.

[0167] Optionally, the processor 910 is also used to read the program from the memory 920 and perform the following steps: In response to the third request, the third signature carried in the third request is verified based on the second private key in the second key pair corresponding to the TSM platform and the first private key in the first key pair corresponding to the business APP. If the third signature verification is successful, a second instruction is sent to the terminal device via transceiver 930; The second instruction carries the DID and the managed information, and also carries a second security domain.

[0168] The electronic device 900 provided in this application embodiment can perform the above-described... Figure 3 The method embodiments shown are similar in principle and technical effect, and will not be described again here.

[0169] This application also provides an electronic device. Since the principle by which this electronic device solves the problem is similar to the SIM card-based key escrow method in this application, the implementation of this electronic device can be found elsewhere. Figure 4 The implementation of the method shown will not be repeated here. Figure 10 As shown, the electronic device according to an embodiment of this application includes: a processor 1010, configured to read a program from a memory 1020 and execute the following processes: The transceiver 1030 receives a second request sent by the terminal device. The second request carries the public key in the master key pair. The master key pair is a key pair generated based on the first managed application. The first managed application is an application installed on the first SIM card in the terminal device. In response to the second request, a DID corresponding to the terminal device is generated based on the public key in the master key pair; The DID is sent to the terminal device via transceiver 1030.

[0170] Among them, Figure 10 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits of one or more processors represented by processor 810 and memory represented by memory 820 together. The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides the interface.

[0171] Optionally, the processor 1010 is also used to read the program from the memory 1020 and perform the following steps: The transceiver 1030 receives a fifth request sent by the operation server of the business APP; wherein, the business APP is an APP pre-deployed on the terminal device; In response to the fifth request, the third public key of the third key pair is sent to the operation server via transceiver 1030. The third key pair is a key pair pre-configured by the identity service platform. The transceiver 1030 receives the first public key sent by the operation server, where the first public key is the public key in the first key pair corresponding to the business APP.

[0172] Optionally, the processor 1010 is also used to read the program from the memory 1020 and perform the following steps: In response to the second request, the second signature carried in the second request is verified based on the first public key; If the second signature verification passes, the DID is generated based on the public key in the master key pair.

[0173] The electronic device 1000 provided in this application embodiment can perform the above-described... Figure 4 The method embodiments shown are similar in principle and technical effect, and will not be described again here.

[0174] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the above-described... Figure 1 , Figure 2 , Figure 3 or Figure 4 The various processes of the SIM card-based key escrow method embodiment are described above, and since they achieve the same technical effect, they will not be repeated here to avoid repetition. The computer-readable storage medium mentioned above includes, for example, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0175] This application embodiment also provides a computer program / program product, which is stored in a storage medium and executed by at least one processor to implement the above. Figure 1 , Figure 2 , Figure 3 or Figure 4 The various processes of the SIM card-based key escrow method embodiment can achieve the same technical effect, and will not be described again here to avoid repetition.

[0176] In the several embodiments provided in this application, it should be understood that the disclosed methods and apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0177] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can be physically included separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0178] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute some steps of the transmission and reception methods described in the various embodiments of this application. 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.

[0179] The above description is the preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principles described in this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A SIM card-based key escrow method applied to a terminal device, characterized in that, The method comprises: sending a first request to a trusted service management (TSM) platform, receiving a first instruction sent by the TSM platform in response to the first request, and installing a first managed application in a first SIM card in the terminal device based on the first instruction; obtaining a master key pair generated based on the first managed application, and sending first information to the TSM platform, the first information comprising managed information corresponding to the master key pair; sending a second request to an identity service platform accessed by a business application (APP) in advance, receiving a DID sent by the identity service platform in response to the second request, and sending the DID to the TSM platform; the second request carries a public key in the master key pair, and the DID is generated by the identity service platform based on the public key in the master key pair; in a case where the first SIM card is replaced by a second SIM card in the terminal device, sending a third request to the TSM platform, and receiving the DID and the managed information sent by the TSM platform in response to the third request; writing the DID and the master key pair corresponding to the first information into the second SIM card.

2. The method of claim 1, wherein, The method comprises: generating the first request in response to an operation instruction of the business APP; wherein the operation instruction comprises a first signature, the first signature is obtained by signing identification information of a target user by a first private key, the first private key is a private key in a first key pair corresponding to the business APP, and the target user is a user logged into the business APP; sending the first request to the TSM platform, the first request carrying the first signature; receiving the first instruction sent by the TSM platform in response to the first request, the first instruction being used to instruct the first SIM card to install the first managed application in a first security domain.

3. The method of claim 2, wherein, The first information further comprises authorization information, and the method comprises: obtaining the authorization information of the key management service in response to an authorization instruction of the business APP to the key management service; generating the managed information corresponding to the master key pair by the first managed application; sending the managed information and the authorization information to the TSM platform.

4. The method of claim 3, wherein, The method comprises: signing second information associated with the business APP by a private key in a first key pair corresponding to the business APP to obtain a second signature; wherein the second information comprises at least one of the authorization information, login information, and identification information of a target user, and the target user is a user logged into the business APP; sending the second request to the identity service platform; wherein the second request carries the second signature. receive the DID generated by the identity service platform in a case where the second signature verification is passed.

5. The method of claim 1, wherein, after the sending of the DID to the TSM platform, the method further comprises: receiving a third instruction sent by the TSM platform; in a case where the first hosting application has generated a sub-key pair corresponding to the business APP, writing the DID into the first SIM card based on the third instruction; in a case where the business APP initiates identity authentication, sending the DID to the TSM platform and receiving identification information of the business APP sent by the TSM platform based on a hosting record table, wherein the hosting record table is used to store a correspondence between the DID and the identification information of the business APP; based on the identification information of the business APP, obtaining a matching rule corresponding to the identification information of the business APP pre-written in the first hosting application; determining the sub-key pair corresponding to the business APP based on the matching rule.

6. The method of claim 3, wherein, in a case where the terminal device replaces the first SIM card with a second SIM card, sending a third request to the TSM platform, comprising: in a case where the terminal device replaces the first SIM card with the second SIM card, encrypting the authorization information based on a second public key and signing the encrypted authorization information based on a first private key to obtain a third signature; sending the third request to the TSM platform, the third request comprising the third signature to be verified; wherein the second public key is a public key pre-sent by the TSM platform to the terminal device, and the first private key is a private key in a first key pair corresponding to the business APP.

7. The method of claim 6, wherein, the receiving of the DID and the hosting information sent by the TSM platform in response to the third request comprises: in a case where the third signature verification is passed, receiving a second instruction sent by the TSM platform in response to the third request, the second instruction comprising the DID and the first information; after the receiving of the DID and the hosting information sent by the TSM platform in response to the third request, the method further comprises: installing a second hosting application in a second security domain of the second SIM card based on the second instruction; wherein the second instruction carries the second security domain, and the second hosting application is used to write the DID and the main key pair into the second SIM card.

8. A SIM card-based key escrow method applied to a TSM platform, characterized in that, the method comprises: receiving a first request sent by a terminal device; in response to the first request, sending a first instruction to the terminal device, the first instruction being used to instruct the terminal device to install a first hosting application in a first SIM card; receiving first information sent by the terminal device, the first information comprising hosting information corresponding to a main key pair, the main key pair being a key pair generated by the first hosting application; receiving a DID sent by the terminal device, the DID being generated by an identity service platform based on a public key in the main key pair; receive a third request sent by the terminal device, and in response to the third request, send the DID and the hosting information to the terminal device.

9. The method of claim 8, wherein, Before the receiving the first request sent by the terminal device, the method further comprises: receiving a fourth request sent by an operation server of a service APP, wherein the service APP is an APP pre-deployed on the terminal device, and the fourth request carries identification information of the service APP; in a case where the operation server has accessed an identity service platform, in response to the fourth request, performing at least one of the following: configuring a third security domain and a third key pair corresponding to the identity service platform, and sending the third security domain and the third key pair to the identity service platform; entering the identification information of the service APP into a whitelist sequence of the TSM platform; configuring a service interface for providing access service for the service APP.

10. The method of claim 9, wherein, After the receiving the DID sent by the terminal device, the method further comprises any one or more of the following: storing the DID into a pre-constructed hosting record table, wherein the hosting record table is used to store a corresponding relationship between the DID and the identification information of the service APP; in a case where the first hosting application has generated a sub-key pair corresponding to the service APP, sending a third instruction to the terminal device, wherein the third instruction is used to instruct writing the DID into the first SIM card; in a case where the service APP initiates identity authentication, receiving the DID sent by the terminal device, and returning the identification information of the service APP corresponding to the DID in the hosting record table to the terminal device.

11. The method according to claim 9 or 10, characterized in that, The sending the DID and the hosting information to the terminal device in response to the third request comprises: in response to the third request, verifying a third signature carried by the third request based on a second private key in a second key pair corresponding to the TSM platform and a first private key in a first key pair corresponding to the service APP; in a case where the third signature verification is passed, sending a second instruction to the terminal device; wherein the second instruction carries the DID and the hosting information, and the second instruction further carries a second security domain.

12. A SIM card-based key escrow method applied to an identity service platform, characterized in that, The method comprises: receiving a second request sent by a terminal device, wherein the second request carries a public key in a master key pair, the master key pair is a key pair generated based on a first hosting application, and the first hosting application is an application program installed on a first SIM card in the terminal device; in response to the second request, generating a DID corresponding to the terminal device based on the public key in the master key pair; sending the DID to the terminal device.

13. The method of claim 12, wherein, Before the receiving the second request sent by the terminal device, the method further comprises: receiving a fifth request sent by an operation server of a service APP, wherein the service APP is an APP pre-deployed on the terminal device; in response to the fifth request, sending a third public key in a third key pair to the operation server, wherein the third key pair is a key pair pre-configured by the identity service platform; receive a first public key sent by the operation server, the first public key being a public key in a first key pair corresponding to the service APP.

14. The method of claim 13, wherein, The DID corresponding to the terminal device is generated based on the public key in the master key pair in response to the second request, and the DID is generated based on the first public key in response to the second request. In response to the second request, the second signature carried by the second request is verified based on the public key in the master key pair. In the case where the second signature verification is passed, the DID is generated based on the public key in the master key pair.

15. A SIM card based key escrow apparatus applied to a terminal device, characterized in that, The device comprises: The first sending module is configured to send a first request to a trusted service management (TSM) platform, receive a first instruction sent by the TSM platform in response to the first request, and install a first managed application in a first SIM card in the terminal device based on the first instruction; The first obtaining module is configured to obtain a master key pair generated based on the first managed application, and send first information to the TSM platform, the first information comprising managed information corresponding to the master key pair; The second sending module is configured to send a second request to an identity service platform accessed by a service application (APP) in advance, receive a DID sent by the identity service platform in response to the second request, and send the DID to the TSM platform; the second request carries a public key in the master key pair, and the DID is generated by the identity service platform based on the public key in the master key pair; The third sending module is configured to, in the case where the first SIM card in the terminal device is replaced with a second SIM card, send a third request to the TSM platform, and receive the DID and the managed information sent by the TSM platform in response to the third request; The first writing module is configured to write the DID and the master key pair corresponding to the first information in the second SIM card.

16. A SIM card based key escrow device applied to a TSM platform, characterized in that, The device comprises: The first receiving module is configured to receive a first request sent by a terminal device; The fourth sending module is configured to, in response to the first request, send a first instruction to the terminal device, the first instruction being used to instruct the terminal device to install a first managed application in a first SIM card; The second receiving module is configured to receive first information sent by the terminal device, the first information comprising managed information corresponding to a master key pair, the master key pair being a key pair generated by the first managed application; The third receiving module is configured to receive a DID sent by the terminal device, the DID being generated by an identity service platform based on a public key in the master key pair; The fourth receiving module is configured to receive a third request sent by the terminal device, and in response to the third request, send the DID and the managed information to the terminal device.

17. A SIM card based key escrow device applied to an identity service platform, characterized in that, The device comprises: The fifth receiving module is configured to receive a second request sent by a terminal device, the second request carrying a public key in a master key pair, the master key pair being a key pair generated based on a first managed application, the first managed application being an application installed in a first SIM card in the terminal device; The first generating module is configured to, in response to the second request, generate a DID corresponding to the terminal device based on the public key in the master key pair. A fifth sending module, configured to send the DID to the terminal device.

18. An electronic device, comprising: Comprising: A processor, a memory, and a program stored on the memory and executable on the processor, the program, when executed by the processor, implements the steps in the SIM card-based key escrow method according to any one of claims 1 to 7, or the steps in the SIM card-based key escrow method according to any one of claims 8 to 11, or the steps in the SIM card-based key escrow method according to any one of claims 12 to 14.

19. A computer readable storage medium for storing a computer program, characterized in that, The computer program, when executed by the processor, implements the steps in the SIM card-based key escrow method according to any one of claims 1 to 7, or the steps in the SIM card-based key escrow method according to any one of claims 8 to 11, or the steps in the SIM card-based key escrow method according to any one of claims 12 to 14.

20. A computer program product, characterised in that, The computer program, when executed by the processor, implements the steps in the SIM card-based key escrow method according to any one of claims 1 to 7, or the steps in the SIM card-based key escrow method according to any one of claims 8 to 11, or the steps in the SIM card-based key escrow method according to any one of claims 12 to 14. The computer program, when executed by the processor, implements the steps in the SIM card-based key escrow method according to any one of claims 1 to 7, or the steps in the SIM card-based key escrow method according to any one of claims 8 to 11, or the steps in the SIM card-based key escrow method according to any one of claims 12 to 14.

Images