Terminal credential acquisition method, apparatus, device, medium, and program product

Abstract

This application relates to a method, apparatus, device, medium, and program product for obtaining terminal credentials. The method includes: in response to triggering a target link, extracting an activation token from the target link via a target application, wherein the target link is a link sent by a server carrying the activation token; invoking a trusted execution environment (TEA) and generating an asymmetric key pair within the TEA; assembling the hardware public key from the asymmetric key pair with the activation token into an activation request packet, and sending the activation request packet to the server; and, if the server verifies the validity of the activation request packet, receiving and storing a structured digital credential returned by the server based on the activation request packet. This method enables secure acquisition of digital credentials without the need to create a cloud account.

Description

Technical Field

[0001] This application relates to the field of computer security technology, and in particular to a method, apparatus, device, medium, and program product for obtaining terminal credentials. Background Technology

[0002] As enterprises deepen their digital transformation, digital identity management systems have become a core infrastructure for ensuring enterprise information security. Meanwhile, passwordless authentication solutions based on rapid online identity authentication standards and access key technology are gradually being natively supported by mainstream operating systems and browsers, providing a technological foundation for eliminating traditional password authentication methods.

[0003] In traditional technologies, systems generally adopt an architecture design that uses cloud accounts as the basic anchor point for identity. Users need to establish account records in the cloud through a registration process and maintain passwords or multi-factor authentication credentials bound to the account; the root private key or user signing key is centrally hosted in a key management system on the server side; all authentication requests are centrally authenticated through the cloud account system. Under this architecture, the issuance process of enterprise digital credentials usually relies on the pre-registered cloud accounts of employees, with the server generating credentials and pushing them to the employee's terminal through a secure channel.

[0004] However, the above solution has at least the following problems: account credentials are vulnerable to phishing and credential stuffing attacks; private keys are centrally stored on servers, and once breached, it will lead to large-scale credential forgery. Summary of the Invention

[0005] Therefore, it is necessary to provide a terminal credential acquisition method, device, equipment, medium, and program product that can securely obtain digital credentials without creating a cloud account, addressing the aforementioned technical issues.

[0006] Firstly, this application provides a terminal credential acquisition method, applied to a mobile terminal, the method comprising:

[0007] In response to triggering a target link, an activation token is extracted from the target link by the target application, the target link being a link sent by the server carrying the activation token;

[0008] Invoke a trusted execution environment and generate an asymmetric key pair within that environment;

[0009] The hardware public key in the asymmetric key pair is assembled with the activation token into an activation request packet, and the activation request packet is sent to the server.

[0010] If the server verifies that the activation request packet is valid, it receives and stores the structured digital credential returned by the server based on the activation request packet.

[0011] In some embodiments of the method, the method further includes:

[0012] If the server verifies that the activation request packet is invalid, the server receives the activation failure response and outputs a first prompt message indicating that the target link is invalid.

[0013] And / or, if the server verifies that the activation request packet exceeds a preset verification time threshold, receive the activation expiration response returned by the server, and output a second prompt message to indicate that the target link has expired.

[0014] In some embodiments of the method, the activation token is configured to be associated with at least one of user information and expiration information, and the step of retrieving the activation token from the target link via the target application in response to triggering the target link includes:

[0015] In response to triggering the target link, the target application is invoked by identifying the route through the operating system;

[0016] The target application extracts at least one of the user information and validity period information of the activation token from the target link.

[0017] In some embodiments of the method, the activation token is configured to be valid only once, and the method further includes:

[0018] If the server verifies that the activation request packet is valid, the activation token is marked as destroyed by the server. When the target application initiates an activation request again using the same activation token, it receives an invalid activation token response from the server.

[0019] In some embodiments of the method, the step of invoking a trusted execution environment and generating an asymmetric key pair within that environment includes:

[0020] The trusted execution environment of the hardware security chip is invoked to generate an asymmetric key pair that is physically isolated and cannot be exported within the trusted execution environment.

[0021] In some embodiments of the method, receiving and storing the structured digital credentials returned by the server based on the activation request packet includes:

[0022] The server receives an encrypted structured digital certificate returned by the server. The structured digital certificate is obtained by the server through digital signature of the subject information, including the hardware public key, using the certificate root private key.

[0023] After the encrypted structured digital credential is decrypted, it is persistently stored in a local isolated secure storage database.

[0024] According to a second aspect of the present disclosure, a terminal credential acquisition device is provided. The device includes:

[0025] A token extraction module is used to extract an activation token from a target link via a target application in response to triggering the target link, wherein the target link is a link sent by the server carrying the activation token;

[0026] The key generation module is used to invoke the trusted execution environment and generate an asymmetric key pair within the trusted execution environment.

[0027] The sending module is used to assemble the hardware public key in the asymmetric key pair and the activation token into an activation request packet, and send the activation request packet to the server.

[0028] The receiving module is configured to receive and store the structured digital credentials returned by the server based on the activation request packet, provided that the server verifies the validity of the activation request packet.

[0029] According to a third aspect of the present disclosure, a computer device is provided. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the aforementioned terminal credential acquisition method.

[0030] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the aforementioned terminal credential acquisition method.

[0031] According to a fifth aspect of the present disclosure, a computer program product is provided. The computer program product includes a computer program that, when executed by a processor, implements the aforementioned terminal credential acquisition method.

[0032] The terminal credential acquisition scheme provided in this application, by responding to the triggering of a target link, extracting an activation token from the target link, calling a trusted execution environment to generate an asymmetric key pair, assembling the hardware public key and the activation token into an activation request packet and sending it to the server, and receiving and storing the structured digital credential if the server verifies its validity, can complete the trust anchoring of terminal credentials without creating a cloud user account. From the system architecture level, it also eliminates the systemic risks caused by the theft of account credentials and centralized private key custody faced by traditional cloud account systems, and realizes a truly server-side zero-private-key credential distribution method.

[0033] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0034] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0035] Figure 1 This is a flowchart illustrating a terminal credential acquisition method according to an exemplary embodiment;

[0036] Figure 2 This is a schematic diagram illustrating the specific process of a terminal credential acquisition method according to an exemplary embodiment;

[0037] Figure 3 This is a structural block diagram of a terminal credential acquisition device according to an exemplary embodiment;

[0038] Figure 4 This is a diagram illustrating the internal structure of a computer device according to an exemplary embodiment. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0040] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure. The terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in a process, method, product, or apparatus that includes said elements is not excluded. For example, the use of terms such as "first," "second," etc., to denote names does not indicate any specific order.

[0041] In some embodiments provided in this disclosure, the execution of the terminal credential acquisition method can be controlled by a unified controller or by multiple controllers. These controllers may include the controller of the local terminal or the controller of a remote server. In some embodiments, the controller of the local terminal and the controller of the server may jointly assist in acquiring the terminal credential. The local terminal mentioned in this disclosure may include, but is not limited to, various robotic devices, vehicle-mounted devices, personal computers, laptops, smartphones, tablets, wearable devices, medical devices, VR (Virtual Reality) devices, etc. The server may also be a server, server cluster, distributed subsystem, cloud processing platform, server containing blockchain nodes, or a combination thereof. The controllers described in this disclosure may include various control units capable of implementing logic processing functions, including but not limited to CPU (Central Processing Unit), PLC (Programmable Logic Controller), ECU (Electronic Control Unit), MCU (Microcontroller Unit), FPGA (Field Programmable Gate Array), and CPLD (Complex Programmable Logic Device), as well as controllers composed of one or more logic function units, chips, etc.

[0042] In some embodiments of this disclosure, a terminal credential acquisition method is provided, applied to a mobile terminal, such as... Figure 1 As shown, it includes the following steps:

[0043] S20. In response to triggering the target link, the target application extracts an activation token from the target link, wherein the target link is a link sent by the server carrying the activation token.

[0044] A target link typically refers to a server-generated, system-level, universal deep link carrying a one-time activation token. Target links can be distributed to users via out-of-band trusted communication channels (such as corporate email). Target links are characterized by one-time validity and time-limited nature; clicking them directly launches the target application installed on the user's device without prior login or account registration.

[0045] The target application typically refers to a digital identity client program deployed on a mobile terminal. Target applications can pre-register operating system-level routing rules, enabling them to be recognized and automatically invoked by the system.

[0046] An activation token is typically a single, high-strength activation credential generated by the server and associated with the end-user's identity. It may contain attributes such as user information and validity period information, and is used to complete the binding verification between the user's identity and the server's pre-set authorization in the subsequent activation process.

[0047] S22. Invoke the trusted execution environment and generate an asymmetric key pair within the trusted execution environment.

[0048] A Trusted Execution Environment (TEE) typically refers to a hardware-isolated, secure execution zone within the main processor of a mobile terminal. The TEE is isolated from other execution environments running a regular operating system on the mobile terminal, providing an independent and protected environment for the storage and processing of sensitive data.

[0049] S24. Assemble the hardware public key in the asymmetric key pair and the activation token into an activation request packet, and send the activation request packet to the server.

[0050] Hardware public keys typically refer to the public key portion of an asymmetric key pair generated within a trusted execution environment.

[0051] An activation request packet typically refers to a data packet sent to the credential issuing server after the asymmetric key pair generation is completed.

[0052] S26. If the server verifies that the activation request packet is valid, receive and store the structured digital credential returned by the server based on the activation request packet.

[0053] Structured digital credentials can be in the Selective Disclosable JWT (SD-JWT) format. SD-JWT is a composite structure consisting of a JWS (JSON Web Signature) signed by the issuer and zero or more disclosures, supporting selective disclosure of portions of the JWS payload. The server uses the credential root private key to digitally sign the subject attribute information containing the hardware public key, generating the structured digital credential. Upon receiving the credential, the client persistently stores it in a local, isolated, secure storage area.

[0054] In some embodiments of this disclosure, a technical solution is implemented by responding to a triggered target link, extracting an activation token from the target link, calling a trusted execution environment to generate an asymmetric key pair, assembling the hardware public key and the activation token into an activation request packet and sending it to the server, and receiving and storing the structured digital credential if the server verifies its validity. This solution enables the trust anchoring of terminal credentials without creating a cloud user account. From the system architecture level, it simultaneously eliminates the systemic risks of account credential theft and centralized private key custody faced by traditional cloud account systems, and realizes a truly server-side zero-private-key credential distribution method.

[0055] In some embodiments of this disclosure, such as Figure 2 As shown, the method further includes:

[0056] 102. If the server verifies that the activation request packet is invalid, receive the activation failure response returned by the server and output a first prompt message indicating that the target link has expired; and / or, 104. If the server verifies that the activation request packet exceeds a preset verification time threshold, receive the activation expiration response returned by the server and output a second prompt message indicating that the target link has expired.

[0057] In some implementations, after receiving the activation request packet from the mobile terminal, the server can verify the validity of the activation token, such as checking whether the activation token is valid and within its validity period. If the activation token is invalid, the server determines that the activation request packet is invalid, returns an activation failure response to the terminal, and the terminal receives the activation failure response through the target application. The terminal then outputs a first prompt message on the user interface indicating that the target link has expired, such as "Activation link has expired, please contact the administrator to obtain a new one," and guides the user to close the current page or return to the initial state.

[0058] In other implementations, the server extracts expiration information from the activation token and compares the current server time with the issuance time and / or expiration time in the expiration information. If the current time exceeds a preset verification time threshold (e.g., 24 hours, 48 ​​hours, or other durations configured according to the security policy after the activation token is issued), the server determines that the activation request packet has expired and returns an activation expiration response to the terminal. After receiving the response through the target application, the terminal outputs a second prompt message on the user interface indicating that the target link has expired, such as "Activation link has expired, please reapply for an activation link," and may further provide an entry link or operation instructions for reapplying.

[0059] In some implementations, the first and second prompts are different to allow users to distinguish between two different failure scenarios: activation token invalidation and activation token expiration. For example, the invalidation scenario corresponds to the activation token already being used or the token itself being invalid, prompting the user to contact the administrator to obtain a new one; the expired scenario corresponds to the activation token exceeding its validity period, prompting the user to reapply through the company's self-service channels. This differentiated prompting provides users with more precise guidance for subsequent operations, preventing them from repeating invalid operations due to an inability to distinguish the cause of failure.

[0060] In some embodiments of this disclosure, by setting dual verification of the activation token's timeliness and single-use validity, and configuring failure and expiration responses respectively, the token can be effectively prevented from being replayed or maliciously reused, thus improving the security of the credential distribution process. At the same time, by outputting prompts to users that distinguish between failure and expiration scenarios, users can be guided to reapply for an activation link after the token expires, thereby improving the user experience while ensuring security.

[0061] In some embodiments of this disclosure, the activation token is configured to be associated with at least one of user information and validity period information. Based on this, S20 includes:

[0062] In response to triggering the target link, the target application is invoked by identifying the route through the operating system;

[0063] The target application extracts at least one of the user information and validity period information of the activation token from the target link.

[0064] In some implementations, the server generates a system-level universal deep link carrying an activation token. When a user clicks this target link on a mobile terminal, the terminal's operating system parses the link, identifies the package name or application identifier of the target application corresponding to the link, and calls the operating system-level application invocation interface to automatically invoke the target application already installed on the terminal. After the target application is invoked, it parses the target link through its internal routing parsing module, extracting the server-preset activation token from the link's path parameters and / or query parameters. The activation token can be encoded using a structured data format, and the token payload includes at least a user information field and a validity period information field. The target application parses the extracted activation token locally, obtains the user information and / or validity period information, and temporarily stores this information in the application's memory space for subsequent assembly of the activation request package.

[0065] In some implementations, activation tokens are configured to associate both user information and validity period information. When generating the activation token, the server encodes the target user's identity (e.g., a corporate email address) and the token's validity period (e.g., issuance and expiration dates) into the token. After retrieving the activation token, the target application can display the user information on the user interface to prompt the user to confirm the correctness of the identity associated with the current operation, preventing accidental operation or clicking on an activation link belonging to someone other than themselves. Simultaneously, the target application can pre-check the validity period information locally. If the local time has exceeded the token's validity period window, the application can directly notify the user that the activation link has expired without sending a request to the server, thus saving terminal bandwidth and server computing resources.

[0066] In some embodiments of this disclosure, the target application is automatically invoked by the operating system to identify the route, achieving a seamless jump from the link to the client without requiring the user to manually enter any information, thus lowering the operational threshold. By associating and binding the activation token with user information and validity period information, the server can confirm the ownership of the credential based on the user information carried in the token and confirm whether the activation request is within the authorized time window based on the validity period information during the verification phase. This achieves precise identity binding and time window control, preventing the token from being abused by unauthorized users.

[0067] In some embodiments of this disclosure, the activation token is configured to be valid only once, and the method further includes:

[0068] If the server verifies that the activation request packet is valid, the activation token is marked as destroyed by the server. When the target application initiates an activation request again using the same activation token, it receives an invalid activation token response from the server.

[0069] In some implementations, after receiving the activation request packet from the terminal, and after all verifications pass and the structured digital certificate is successfully issued, the server atomically updates the status of the activation token to "destroyed." If, upon receiving the activation request packet, the server finds that the activation token's status is "destroyed," it returns an "invalid activation token" response to the terminal. Upon receiving this response, the target application outputs a third notification to the user interface indicating that the target link has been used. The target application can automatically clear the locally cached activation token and related temporary data to avoid inconsistencies caused by residual local data.

[0070] In other implementations, after verifying the validity of the activation token, the server first atomically updates the token's status to "destroyed" or deletes the token from the cache. Only after the destruction operation is successful does the server proceed with the signing of the credential root private key and the issuance of the structured digital credential. If the destruction operation fails, the server immediately terminates the subsequent process and returns a system error response without issuing the credential. This processing order ensures that even if a network anomaly or terminal failure occurs during credential issuance, the token cannot be reused for activation, guaranteeing strong consistency of single-use validity in terms of timing.

[0071] In some embodiments of this disclosure, the activation token is single-use only. After verifying the validity of the activation token, the server immediately destroys the token. This ensures that even if the activation request packet is intercepted during transmission, an attacker cannot use the same token to initiate an activation request again, thereby completely eliminating the risk of token replay attacks and avoiding the storage overhead caused by the server maintaining a large number of used token records.

[0072] In some embodiments of this disclosure, S22 includes:

[0073] The trusted execution environment of the hardware security chip is invoked to generate an asymmetric key pair that is physically isolated and cannot be exported within the trusted execution environment.

[0074] In some implementations, the hardware security chip may be a security processor integrated into the main processor of the mobile terminal or a separate security element. It is separated from the terminal's Rich Execution Environment (REE) by hardware-level physical isolation and has an independent processor, encryption engine, and storage area, which can resist software-level attacks and physical-level side-channel attacks.

[0075] In some implementations, after the target application is activated, it directly invokes a hardware-level trusted execution environment to generate a hardware-isolated asymmetric key pair. The asymmetric key pair is non-derivative, fundamentally eliminating the risk of data breaches in the cloud or malicious copying of the client's private key.

[0076] In some embodiments of this disclosure, an asymmetric key pair is generated by calling the trusted execution environment of the hardware security chip. The private key is non-exportable, which fundamentally eliminates the risk of the private key being maliciously copied or exported. Even if the terminal operating system is compromised or the application is reverse engineered, the attacker cannot obtain the private key.

[0077] In some embodiments of this disclosure, S26 includes:

[0078] The server receives an encrypted structured digital certificate returned by the server. The structured digital certificate is obtained by the server through digital signature of the subject information, including the hardware public key, using the certificate root private key.

[0079] After the encrypted structured digital credential is decrypted, it is persistently stored in a local isolated secure storage database.

[0080] In some implementations, after receiving the encrypted structured digital certificate from the server, the client first decrypts the ciphertext using locally stored key materials to restore the plaintext data of the structured digital certificate. After decryption, the client persistently stores the structured digital certificate in a local, isolated secure storage area. This isolated secure storage area is isolated from the target application's ordinary data storage area, preventing other functional modules or third-party applications from directly accessing the data in this storage area, thus preventing unauthorized reading or export of the certificate.

[0081] In some implementations, the structured digital credential includes a hardware public key, which is the public key in the asymmetric key pair generated within the TEE. The server signs the subject attribute information containing this public key using the credential root private key, establishing a trust binding relationship between the hardware public key and the enterprise digital identity. When the client subsequently uses the credential, it can perform a signing operation using the corresponding private key within the TEE, and the server verifies the signature using the hardware public key recorded in the credential, thereby achieving terminal identity authentication based on a hardware root of trust.

[0082] In some implementations, the subject attribute information includes, in addition to the hardware public key, at least one of the following: user identification information (e.g., corporate email or employee ID), credential issuance and expiration dates, and credential access permissions. When issuing structured digital credentials, the server incorporates this attribute information into the signature to ensure that the credential's attributes cannot be tampered with. When presenting credentials subsequently, the client can disclose only some attribute information based on actual business needs, thereby minimizing information disclosure and protecting user privacy.

[0083] In some implementations, after the client persistently stores the structured digital credential, the target application can read the credential from a locally isolated secure storage area when the terminal is offline. This credential can then be used to prove the holder's digital identity to enterprise intranet applications or services. Because the credential contains a digital signature of the server's root private key, and the credential itself is bound to the hardware private key in the terminal's TEE, even if the terminal is in a network-free environment, other applications or services can verify the authenticity of the identity by verifying the credential signature after receiving the credential, thereby achieving offline availability of the digital credential.

[0084] In some embodiments of this disclosure, the server uses structured digital credentials, and the client decrypts the encrypted credentials and persistently stores them in a local isolated secure storage database. This ensures the offline availability of credentials on the terminal side, so that even if the terminal is in a network-free environment, the user can still complete the authentication based on the locally stored credentials. On the other hand, due to the selective disclosure characteristics of structured digital credentials, the terminal only discloses the necessary minimal information when presenting credentials later, thus achieving a balance between privacy protection and functional availability.

[0085] The terminal credential acquisition methods disclosed herein, by responding to a triggered target link, extracting an activation token from the target link, calling a trusted execution environment to generate an asymmetric key pair, assembling the hardware public key and the activation token into an activation request packet and sending it to the server, and receiving and storing the structured digital credential if the server verifies its validity, can complete the trust anchoring of terminal credentials without creating a cloud user account. From the system architecture level, this also eliminates the systemic risks caused by the theft of account credentials and centralized private key custody faced by traditional cloud account systems, and realizes a truly server-side zero-private-key credential distribution method.

[0086] It is understood that the various embodiments of the methods described in this specification are presented in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. Related details can be found in the descriptions of other method embodiments.

[0087] It should be understood that although the steps in the flowcharts shown in the accompanying drawings are displayed sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the accompanying drawings may include multiple steps or stages, which are not necessarily completed at the same time, but may be executed at different times, and the execution order of these steps or stages is not necessarily sequential, but may be performed alternately or in turn with other steps or at least a portion of the steps or stages of other steps.

[0088] Based on the description of the terminal credential acquisition method embodiments described above, this disclosure also provides a terminal credential acquisition device for implementing the aforementioned terminal credential acquisition method. The device may include a system (including a distributed system), software (application), module, component, controller, server, terminal, etc., using the method described in the embodiments of this specification, combined with necessary hardware implementation. Based on the same innovative concept, the devices in one or more embodiments provided by the embodiments of this disclosure are as described in the following embodiments. Since the implementation schemes and methods for solving the problem by the devices are similar, the implementation of specific devices in the embodiments of this specification can refer to the implementation of the aforementioned method, and repeated details will not be repeated. As used below, the terms "unit" or "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0089] Figure 3 This is a schematic block diagram illustrating a terminal credential acquisition device according to an exemplary embodiment. The device can be the aforementioned terminal, a server, or a module, component, device, control unit, etc., integrated into the terminal. For details, please refer to... Figure 3 The device 100 may include: a token extraction module 120, a key generation module 140, a sending module 160, and a receiving module 180. Specifically, the token extraction module 120 is used to extract an activation token from a target link (a link sent by a server carrying the activation token) in response to triggering a target link; the key generation module 140 is used to invoke a trusted execution environment (TEA) and generate an asymmetric key pair within the TEA; the sending module 160 is used to assemble the hardware public key from the asymmetric key pair with the activation token into an activation request packet and send the activation request packet to the server; and the receiving module 180 is used to receive and store the structured digital credential returned by the server based on the activation request packet, provided that the server verifies the validity of the activation request packet.

[0090] Each module in the aforementioned terminal credential acquisition device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0091] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 4As shown, the computer device includes a processor, memory, communication interface, display screen, and input device connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When executed by the processor, the computer program implements a terminal credential acquisition method.

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

[0093] Based on the foregoing description of the relevant methods and apparatus embodiments, this disclosure also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, it implements the terminal credential acquisition method described in any embodiment of this specification.

[0094] Based on the foregoing description of the relevant methods and apparatus embodiments, this disclosure also provides a computer-readable storage medium that, when the instructions in the computer-readable storage medium are executed by the processor of a computer device, enables the computer device to implement the terminal credential acquisition method as described in any embodiment of this disclosure.

[0095] Based on the foregoing description of the relevant methods and apparatus embodiments, this disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the terminal credential acquisition method described in any embodiment of this specification.

[0096] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, hardware + program embodiments are relatively simple in description because they are fundamentally similar to method embodiments; relevant parts can be referred to the descriptions in the method embodiments.

[0097] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0098] It should be noted that the apparatus, computer equipment, storage medium, and computer program products described above may also include other implementation methods according to the description of the method embodiments. Specific implementation methods can be found in the description of the relevant method embodiments. Furthermore, new embodiments formed by combinations of features from various methods, apparatuses, devices, and server embodiments still fall within the scope of this disclosure and will not be elaborated upon here.

[0099] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of modules or units is only a logical functional division; 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 and communication connections between the devices or units shown or described can be implemented through direct and / or indirect coupling / connection, through standard or custom interfaces or protocols, and can be implemented electrically, mechanically, or in other forms.

[0100] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0101] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.

Claims

1. A terminal credential acquisition method, characterized by, Applied to a mobile terminal, the method includes: In response to triggering a target link, an activation token is extracted from the target link by the target application, the target link being a link sent by the server carrying the activation token; Invoke a trusted execution environment and generate an asymmetric key pair within that environment; The hardware public key in the asymmetric key pair is assembled with the activation token into an activation request packet, and the activation request packet is sent to the server. If the server verifies that the activation request packet is valid, it receives and stores the structured digital credential returned by the server based on the activation request packet.

2. The method of claim 1, wherein, The method further includes: If the server verifies that the activation request packet is invalid, the server receives the activation failure response and outputs a first prompt message indicating that the target link is invalid. And / or, if the server verifies that the activation request packet exceeds a preset verification time threshold, receive the activation expiration response returned by the server, and output a second prompt message to indicate that the target link has expired.

3. The method of claim 1, wherein, The activation token is configured to be associated with at least one of user information and validity period information. The step of retrieving the activation token from the target application via the target link in response to triggering the target link includes: In response to triggering the target link, the target application is invoked by identifying the route through the operating system; The target application extracts at least one of the user information and validity period information of the activation token from the target link.

4. The method of claim 3, wherein, The activation token is configured to be valid only once, and the method further includes: If the server verifies that the activation request packet is valid, the activation token is marked as destroyed by the server. When the target application initiates an activation request again using the same activation token, it receives an invalid activation token response from the server.

5. The method of claim 1, wherein, The invocation of the trusted execution environment, and the generation of an asymmetric key pair within the trusted execution environment, includes: The trusted execution environment of the hardware security chip is invoked to generate an asymmetric key pair that is physically isolated and cannot be exported within the trusted execution environment.

6. The method of claim 1, wherein, The process of receiving and storing the structured digital credential returned by the server based on the activation request packet includes: The server receives an encrypted structured digital certificate returned by the server. The structured digital certificate is obtained by the server through digital signature of the subject information, including the hardware public key, using the certificate root private key. After the encrypted structured digital credential is decrypted, it is persistently stored in a local isolated secure storage database.

7. A terminal credential acquisition apparatus characterized by comprising: The device includes: A token extraction module is used to extract an activation token from a target link via a target application in response to triggering the target link, wherein the target link is a link sent by the server carrying the activation token; The key generation module is used to invoke the trusted execution environment and generate an asymmetric key pair within the trusted execution environment. The sending module is used to assemble the hardware public key in the asymmetric key pair and the activation token into an activation request packet, and send the activation request packet to the server. The receiving module is configured to receive and store the structured digital credentials returned by the server based on the activation request packet, provided that the server verifies the validity of the activation request packet.

8. A computer device, comprising: It includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, It stores a computer program thereon, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, characterised in that, Includes a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 1 to 6.

Images