Login ticket acquisition method and device, equipment and storage medium

Abstract

The application belongs to the technical field of computers and particularly relates to a login ticket acquisition method and device, equipment and a storage medium. The method comprises the following steps: a client sends a login request to a server; the server determines at least two preset login tickets in response to the login request and generates at least two pairs of key pairs based on a server private key and a client public key; the server encrypts each preset login ticket based on a downlink key in the key pair corresponding to the preset login ticket to obtain a ticket encryption result; the server sends the ticket encryption result and a server public key to the client; the client obtains at least two pairs of key pairs based on the server public key and a client private key; and the client decrypts the ticket encryption result based on a downlink key in each pair of key pairs to obtain a preset login ticket. The preset login ticket is encrypted, thereby reducing the exposure risk of the preset login ticket in the transmission process.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and specifically relates to a method, apparatus, device and storage medium for obtaining login tickets. Background Technology

[0002] With the continuous development of mobile terminals and network technology, and the increasing popularity of mobile office, enterprises and government agencies have developed office application systems that include various business functions. These office application systems typically integrate a large number of internal business processes.

[0003] Single Sign-On (SSO) is a commonly used solution for enterprise business integration. SSO allows users to access all trusted applications by logging in only once. The key to SSO is the use of tickets for authentication. However, in related technologies, tickets used for authentication are often transmitted in plaintext, increasing the risk of them being compromised, hijacked, or exposed during transmission. Furthermore, since all business processes within an application system can currently use the same ticket for authentication, a leaked ticket could compromise the security of the entire application system. Summary of the Invention

[0004] To address the aforementioned technical problems, this application provides a method, apparatus, device, and storage medium for obtaining login tickets. By encrypting at least two preset login tickets using downlink key pairs from different key pairs, the risk of exposure of preset login tickets during transmission is reduced. Furthermore, the business system sets multiple preset login tickets for the client, avoiding the global security risk caused by the leakage of a single preset login ticket.

[0005] On one hand, this application proposes a method for obtaining a login ticket, the method comprising:

[0006] In response to a login request sent by a local client, at least two preset login tickets are determined; the login request carries the client's public key; the client's public key is generated based on preset parameters negotiated between the client and the local server; the preset login ticket is the client's login credential in a preset business system or the login credential of a target business site in the preset business system;

[0007] At least two key pairs are generated based on the server's private key and the client's public key; the server's private key is generated based on preset parameters; each key pair corresponds to a preset login ticket; each key pair includes a downlink key; the downlink key is used to encrypt data sent from the local server to the client;

[0008] Based on the downlink key in the key pair corresponding to each preset login ticket, each preset login ticket is encrypted to obtain the ticket encryption result;

[0009] The ticket encryption result and the server's public key are sent to the client so that the client can obtain at least two key pairs based on the server's public key and the client's private key. The client can then decrypt the ticket encryption result based on the downlink key in each key pair to obtain the preset login ticket. The server's public key and the client's private key are generated based on preset parameters.

[0010] On the other hand, embodiments of this application provide a method for obtaining login tickets, the method comprising:

[0011] A login request is sent to the local server, prompting the server to respond. The server determines at least two preset login tickets and generates a key pair for each ticket based on its private key and the client's public key. The server then encrypts each preset login ticket using the downlink key in its key pair, resulting in an encrypted ticket. The login request carries the client's public key, which is generated based on preset parameters negotiated between the local client and the server. The preset login ticket is either the local client's login credential in a preset business system or a login credential for a target business site within that system. The server's private key is generated based on preset parameters. Each key pair includes a downlink key used to encrypt data sent from the server to the local client.

[0012] Receive the encrypted ticket result sent by the server and send the server's public key; the server's public key is generated based on preset parameters;

[0013] At least two key pairs are obtained based on the server's public key and the client's private key; the client's private key is generated based on preset parameters.

[0014] The encrypted ticket is decrypted based on the downlink key in each key pair to obtain the preset login ticket.

[0015] On the other hand, embodiments of this application provide a login ticket acquisition device, the device comprising:

[0016] The preset login ticket acquisition module is used to respond to login requests sent by local clients and determine at least two preset login tickets. The login request carries the client's public key. The client's public key is generated based on preset parameters negotiated between the client and the local server. The preset login ticket is the client's login credential in a preset business system or the login credential of a target business site in the preset business system.

[0017] The key pair generation module is used to generate at least two key pairs based on the server's private key and the client's public key; the server's private key is generated based on preset parameters; each key pair corresponds to a preset login ticket; each key pair includes a downlink key; the downlink key is used to encrypt data sent from the local server to the client;

[0018] The encryption module is used to encrypt each preset login ticket based on the downlink key in the key pair corresponding to each preset login ticket, and obtain the ticket encryption result;

[0019] The sending module is used to send the ticket encryption result and the server's public key to the client, so that the client can obtain at least two key pairs based on the server's public key and the client's private key, and decrypt the ticket encryption result based on the downlink key in each key pair to obtain the preset login ticket; the server's public key and the client's private key are generated based on preset parameters.

[0020] On the other hand, embodiments of this application provide a login ticket acquisition device, the device comprising:

[0021] The login request sending module is used to send a login request to the local server, so that the server responds to the login request, determines at least two preset login tickets, and generates a key pair corresponding to each preset login ticket based on the server's private key and the client's public key. The server then encrypts each preset login ticket based on the downlink key in the key pair corresponding to each preset login ticket, obtaining the ticket encryption result. The login request carries the client's public key, which is generated based on preset parameters negotiated between the local client and the server. The preset login ticket is the login credential of the local client in a preset business system or the login credential of the target business site in the preset business system. The server's private key is generated based on preset parameters. Each key pair includes a downlink key, which is used to encrypt data sent by the server to the local client.

[0022] The receiving module is used to receive the encrypted ticket result and the server's public key sent by the server; the server's public key is generated based on preset parameters.

[0023] The key pair determination module is used to obtain at least two key pairs based on the server's public key and the client's private key; the client's private key is generated based on preset parameters.

[0024] The decryption module is used to decrypt the encrypted ticket based on the downlink key in each key pair to obtain the preset login ticket.

[0025] On the other hand, this application proposes an electronic device for obtaining login tickets, the electronic device including a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or at least one program being loaded and executed by the processor to implement the login ticket obtaining method as described above.

[0026] On the other hand, this application proposes a computer-readable storage medium storing at least one instruction or at least one program, which is loaded and executed by a processor to implement the login ticket acquisition method as described above.

[0027] On the other hand, this application proposes a computer program product that, when executed by a processor, implements the login ticket acquisition method as described above.

[0028] The login ticket acquisition method, apparatus, electronic device, and storage medium proposed in this application, when a client initiates a login request, generate multiple key pairs and use the downlink key from these key pairs to encrypt at least two predetermined login tickets. The encryption results are then transmitted to the client, and key negotiation is used to obtain multiple key pairs for the client to decrypt the encryption results and obtain the predetermined login tickets. This method uses encryption to transmit the predetermined login tickets, reducing the risk of exposure during transmission and thus improving the security of the business system. Furthermore, by setting multiple predetermined login tickets for the client initiating the login request, the global security risk caused by the leakage of a single predetermined login ticket can be avoided, further enhancing the security of the business system. Attached Figure Description

[0029] To more clearly illustrate the technical solutions and advantages in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art 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.

[0030] Figure 1 This is a schematic diagram illustrating the implementation environment of a login ticket acquisition method according to an exemplary embodiment.

[0031] Figure 2 This is a flowchart illustrating a login ticket acquisition method according to an exemplary embodiment. Figure 1 .

[0032] Figure 3 This is a schematic diagram of a login ticket process according to an exemplary embodiment. Figure 2.

[0033] Figure 4 This is a flowchart illustrating a login ticket acquisition method with the server as the execution subject, according to an exemplary embodiment.

[0034] Figure 5 This is a flowchart illustrating a login ticket acquisition method with a client as the execution subject, according to an exemplary embodiment.

[0035] Figure 6 This is a block diagram of a login ticket acquisition device according to an exemplary embodiment.

[0036] Figure 7 This is a block diagram of another login ticket acquisition device according to an exemplary embodiment.

[0037] Figure 8 This is a hardware structure block diagram of a server for a login ticket acquisition method provided according to an exemplary embodiment. Detailed Implementation

[0038] 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, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0039] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of the embodiments of this application 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 embodiments of the present application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or devices.

[0040] To make the objectives, technical solutions, and advantages disclosed in the embodiments of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely illustrative of the embodiments of this application and are not intended to limit the embodiments of this application.

[0041] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

[0042] Office automation (OA) systems can connect with daily tasks through specific processes or steps, improving efficiency in document circulation, approval, and publication, achieving standardized office management and information, and reducing enterprise operating costs. In the authentication system of OA systems, tickets are typically used for identity authentication and device security authentication. However, in the ticket authentication process when accessing business transactions, the ticket used for identity authentication is often transmitted in plaintext, increasing the risk of ticket transmission being compromised or hijacked, thus exposing the ticket. Currently, besides using secure transmission protocols at the transmission protocol level, such as Hypertext Transfer Protocol Secure (HTTPS) and Transport Layer Security (TLS), there is a lack of other security mechanisms to ensure the secure transmission of tickets. Furthermore, in OA systems, all business transactions can use the same ticket for authentication without ticket isolation, which increases the global risk caused by single-point leakage.

[0043] In view of this, embodiments of this application provide a login ticket acquisition method, apparatus, electronic device, and storage medium. When a client initiates a login request, multiple key pairs are generated, and the downlink key from these key pairs is used to encrypt at least two predetermined login tickets. The encryption results are then transmitted to the client, and a key negotiation method is used to allow the client to obtain multiple key pairs, enabling the client to decrypt the encryption results and obtain the predetermined login ticket. By generating multiple parallel key pairs, the encrypted transmission between different predetermined login tickets can be achieved under conditions of multi-level parallel client operations and multiple pairs of predetermined login tickets at the same level operating in parallel. Furthermore, even without explicit text transmission of the predetermined login ticket, the authentication of the predetermined login ticket is completed through an encryption / decryption negotiation process between the client and the backend, reducing the risk of exposure of the predetermined login ticket during transmission and enhancing its security, thereby improving the security of the business system. In addition, by setting multiple predetermined login tickets for the client initiating the login request, the global security risk caused by the leakage of a single predetermined login ticket can be avoided, further improving the security of the business system.

[0044] Figure 1This is a schematic diagram illustrating an implementation environment for a login ticket acquisition method according to an exemplary embodiment. For example... Figure 1 As shown, the implementation environment may include at least a client 01 and a server 02. The client 01 and the server 2 may be directly or indirectly connected via wired or wireless communication, which is not limited in this application.

[0045] In this embodiment, client 01 can send a login request to server 02, causing server 02 to respond to the login request, determine at least two preset login tickets, generate a key pair corresponding to each preset login ticket based on the server's private key and the client's public key, and encrypt each preset login ticket based on the downlink key in the key pair corresponding to each preset login ticket to obtain a ticket encryption result. Client 01 can also receive the ticket encryption result and server public key sent by server 02; the server public key is generated based on preset parameters, and at least two key pairs are obtained based on the server public key and the client's private key, and the ticket encryption result is decrypted based on the downlink key in each key pair to obtain the preset login ticket. Optionally, client 01 can be a smartphone, tablet, laptop, desktop computer, smart speaker, smart voice interaction device, smart home appliance, smartwatch, vehicle terminal, aircraft, etc., but is not limited to these.

[0046] In this embodiment, server 02 can respond to a login request sent by client 01 by determining at least two preset login tickets and generating at least two key pairs based on the server's private key and the client's public key. Server 02 can also encrypt each preset login ticket based on the downlink key in the key pair corresponding to each preset login ticket, obtaining a ticket encryption result, and send the ticket encryption result and the server's public key to client 01. This allows client 01 to obtain at least two key pairs based on the server's public key and the client's private key, and to decrypt the ticket encryption result based on the downlink key in each key pair to obtain the preset login ticket. Optionally, server 02 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0047] It should be noted that, Figure 1 This is just one example. Other implementation environments may also be included in other scenarios.

[0048] Figure 2 This is a flowchart illustrating a login ticket acquisition method according to an exemplary embodiment. Figure 1 This method can be used for Figure 1 In the implementation environment described herein, the login ticket acquisition method steps are provided as illustrated in the embodiments or flowcharts. However, based on conventional or non-inventive labor, more or fewer steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual system or server product execution, the login ticket acquisition method can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment) as shown in the embodiments or drawings. Specifically, as follows... Figure 2 As shown, the method may include:

[0049] S101: The client sends a login request to the server.

[0050] In this embodiment, when a client user first logs into a target business site within a preset business system to perform business processing, they can initiate a login request to the server through the webpage or application corresponding to the preset business system on the client side to log in to the preset business system. Optionally, the preset business system can be an office automation system that provides login functionality, or it can be social software, shopping websites, or video applications that provide login functionality. The preset business system can include multiple business sites that can provide business services. The target business site is one or more of the multiple business sites within the preset business system. For example, if the preset business system is an automated office system that can provide business services such as administrative approval, announcement publication, and meeting reservation, the site corresponding to each business service is a business site.

[0051] In this embodiment of the application, there are various ways for the client to send a login request to the server. For example, the client can send a login request by entering an account and password on the login interface of a preset business system, or by entering an SMS verification code on the login interface of a preset business system, or by scanning a QR code on the login interface of a preset business system. This embodiment of the application does not impose too many limitations on these methods.

[0052] S103: In response to the login request, the server determines at least two preset login tickets and generates at least two key pairs based on the server's private key and the client's public key.

[0053] In this embodiment, the login request carries login information, which can be an account and password, or client device information, etc. After receiving the login request from the client, the server parses the request to obtain the login information and then verifies it. If the verification fails, the server rejects the client's login request. If the verification passes, the server generates a preset login ticket for the client. The preset login ticket is the client's login credential in a preset business system or the login credential for a target business site within the preset business system. Setting preset login tickets can improve login efficiency and the user experience. When a client first uses or accesses a target business site in the preset business system, they can log in by entering their account and password. To avoid having to enter the account and password every time the client uses or accesses the target business site, a preset login ticket for the preset business system and a preset login ticket for the target business site can be generated after the client successfully logs in for the first time. These preset login tickets can include the client's login credential in the preset business system and the login credential for the target business site within the preset business system. In this way, after a successful initial login, when the client needs to log in again, it can quickly and conveniently log in using these preset login tickets.

[0054] In some embodiments, after receiving a login request from a client, the server can also authenticate the client's login permissions based on the login information carried in the request, and then generate different preset login tickets for the client based on the client's login permissions. Specifically, the server determines whether the client has login permissions for a preset business system and for each business site within that system. When the server determines that the client has login permissions for the preset business system, it generates a first-level login ticket for the client, allowing the client to quickly and easily log in to the preset business system. When the server determines that the client has login permissions for both the preset business system and a specific business site within that system, it generates a second-level login ticket for that business site, allowing the client to quickly and easily log in to that business site.

[0055] In this embodiment, the preset login ticket generated by the server for the client needs to be sent to the client so that the client can access the target business site in the preset business system again through the preset login ticket. To prevent the preset login ticket from being exposed during transmission, it can be encrypted with a high-security key to ensure the secure transmission of the preset login ticket. Accordingly, when the server encrypts the preset login ticket with a high-security key, the client needs to obtain the key to decrypt it and obtain the preset login ticket.

[0056] In this embodiment, the server and client can negotiate a high-security key through key negotiation. Key negotiation can occur before the client initiates a login request to the server, or it can occur simultaneously with the client's login request. As an example, before logging into a preset business system, such as when registering an account on the server, the client negotiates the encryption / decryption method for the preset login ticket with the server. During key negotiation, the client can send a key negotiation request to the server. Upon receiving the key negotiation request, the server responds by generating preset parameters and sending them to the client. The server can generate a server public key and a server private key based on the preset parameters. The server public key is sent to the client so that the client receives at least two key pairs. The server private key enables the server to generate at least two key pairs based on the client's public key and server private key. The client can generate its own public key and client private key based on the preset parameters. The client's public key is sent to the server so that the server can generate at least two key pairs based on the client's public key. The client's private key is used by the client to obtain at least two key pairs based on the server's public key and the client's private key. The server and client negotiate key pairs to encrypt / decrypt the preset login ticket, which can improve the security of the preset login ticket during transmission.

[0057] In this embodiment, when the server sends preset parameters to the client, it can also simultaneously send the relevant key generation algorithm to the client, so that the client can calculate the key based on the preset parameters and the key generation algorithm. The relevant algorithm for key negotiation between the server and the client can include a key generation algorithm. Optionally, the key generation algorithm can be an elliptic curve algorithm, such as the X25519 elliptic curve algorithm. The X25519 elliptic curve algorithm has superior security performance and can guarantee the security of the key negotiation mechanism. The server generates preset parameters based on the key exchange algorithm, and then generates a server public key and a server private key based on the preset parameters. As an example, the preset parameters generated by the server based on the key exchange algorithm are p and g. Here, the preset parameter p is a large prime number, and the preset parameter g is an integer less than p. Then, the server selects an integer a as the server private key and calculates the server public key based on the preset parameters and the server private key. The specific calculation formula is: (g^a) mod p.

[0058] In this embodiment, after receiving the preset parameters sent by the client, the client can generate a client private key and a client public key based on a key exchange algorithm. As an example, the preset parameters received by the client are p and g. Then, the client selects an integer b as the client private key and calculates the client public key based on the preset parameters and the client private key. The specific calculation formula is: (g^b) mod p.

[0059] In some embodiments, the server and client negotiate the encryption / decryption key for the preset login ticket, which can also be done after the server generates the preset ticket. That is, after generating the preset login ticket, the server generates preset parameters based on the selected key generation algorithm, and then sends the preset parameters to the client.

[0060] In this embodiment, when encrypting a preset login ticket, the server needs to determine a key pair based on the client's public key, and then encrypt the preset login ticket based on the key pair. Specifically, when the client sends a login request to the server, the login request carries a client public key generated based on preset parameters negotiated between the client and the server. Then, the server generates at least two key pairs based on the server's private key and the client's public key.

[0061] In this embodiment, when the server generates at least two key pairs based on its private key and the client's public key, to ensure higher security, a shared key is first generated using the server's private key and the client's public key. Then, a preset key derivation algorithm is used to derive the shared key, resulting in at least two key pairs. As an example, the calculation method for generating the shared key based on the server's private key and the client's public key is: (((g^b)mod p)^a)mod p. The preset key derivation algorithm is negotiated between the server and the client, allowing the client to also calculate key pairs using this algorithm. Optionally, the preset key derivation algorithm can be a key derivation algorithm, such as the HKDF (HMAC-based Key Derivation Function) algorithm. By using the preset key derivation algorithm to derive one or more key pairs with cryptographic strength from the shared key generated based on the server's private key and the client's public key, while maintaining randomness, the transmission security of the preset login ticket is ensured.

[0062] As an optional implementation, the preset key derivation algorithm includes a first preset key derivation algorithm and a second preset key derivation algorithm. When the server performs derivation processing on the shared key based on the preset key derivation algorithm, the server first performs key extraction and expansion processing on the shared key based on the first preset key derivation algorithm to obtain the master key. Then, the server performs derivation processing on the master key based on the second preset key derivation algorithm to obtain at least two key pairs. In this implementation, the first preset key derivation algorithm and the second preset key derivation algorithm can be the same or different. Optionally, both the first preset key derivation algorithm and the second preset key derivation algorithm can be the HKDF algorithm. When performing derivation processing on the shared key based on the first preset key derivation algorithm, it can include two processes: extraction processing and expansion processing. The extraction processing process derives a pseudo-random key that meets cryptographic strength requirements using the shared key. The expansion processing process uses the pseudo-random key extracted in the extraction processing step to expand the master key to a specified length while ensuring randomness. When performing derivation processing on the master key based on the second preset key derivation algorithm, the expansion processing method in the HKDF algorithm can be used to expand the master key, thereby obtaining multiple key pairs. By sequentially deriving the shared key using the first and second preset key derivation algorithms, multiple pairs of highly secure key pairs can be obtained. This allows for the separate encryption of multiple preset login tickets, thereby avoiding the global security risk caused by a single point of leakage of preset login tickets.

[0063] In this embodiment, the number of key pairs derived from the shared key can be the same as the number of preset login tickets that need to be transmitted; that is, each preset login ticket that needs to be transmitted corresponds to a key pair. Each key pair includes an uplink key and a downlink key. The downlink key is used to encrypt data sent from the server to the client. The uplink key is used to encrypt data sent from the client to the server. By using the uplink key and downlink key to encrypt the preset login tickets transmitted between the client and the server respectively, the encryption failure due to key leakage during transmission can be prevented, thereby improving the security of the preset login tickets transmitted between the client and the server.

[0064] In some embodiments, the number of key pairs derived from the shared key can be greater than the number of preset login tickets that need to be transmitted. Theoretically, a preset business system includes multiple business sites, and for each business site, the server can generate a corresponding preset login ticket for the client. For the preset login tickets corresponding to all business sites in the preset business system, each preset login ticket needs to be encrypted / decrypted using a key pair during transmission. These key pairs can be generated simultaneously by the server, and some or all of these key pairs can be used to encrypt / decrypt the preset login tickets as needed.

[0065] S105: The server encrypts each preset login ticket based on the downlink key in the key pair corresponding to each preset login ticket, and obtains the ticket encryption result.

[0066] In this embodiment, after determining multiple key pairs, the server can encrypt the preset login ticket based on the downlink key in each key pair before sending the preset login ticket to the client, thereby ensuring the security of the preset login ticket transmission.

[0067] In this embodiment, since the preset login tickets corresponding to different business sites in the preset business system are different, encryption of different preset tickets requires encryption based on the key pair corresponding to each preset ticket. Specifically, at least two preset login tickets include a first preset login ticket and at least one second preset login ticket. The first preset login ticket is the client's login credential in the preset business system. The second login ticket is the client's login credential in the target business site. The at least two key pairs include a first key pair and at least one second key pair. The first key pair corresponds to the first preset login ticket, and the second key pair corresponds one-to-one with the second preset login ticket. When the server encrypts each preset login ticket based on the downlink key in the key pair corresponding to each preset login ticket, it encrypts the first preset login ticket based on the downlink key in the first key pair to obtain a first encryption result. Based on the downlink key in each second key pair, it encrypts the second preset login ticket corresponding to each second key pair to obtain a second encryption result. Then, the server combines the first encryption result and the second encryption result to obtain the ticket encryption result. Each preset login ticket that needs to be transmitted is encrypted with a corresponding downlink key, thereby avoiding the global security risk caused by a single point of leakage of the preset login ticket.

[0068] S107: The server sends the encrypted ticket result and the server's public key to the client.

[0069] In this embodiment, the server encrypts a preset ticket using the downlink key in the key pair to obtain the encrypted ticket result, and then sends the encrypted ticket result to the client so that the client can obtain the preset login ticket. After receiving the encrypted ticket result sent by the server, the client needs to obtain the key pair to decrypt the encrypted ticket result, thereby obtaining the preset login ticket. When determining the key pair, the client needs to obtain the server's public key for calculation; therefore, when the server sends the encrypted ticket result to the client, it can also send the server's public key to the client simultaneously.

[0070] S109: The client obtains at least two key pairs based on the server's public key and the client's private key.

[0071] In this embodiment, after obtaining the server's public key, the client performs key calculations based on the server's public key and its own private key to obtain at least two key pairs. Specifically, when the client obtains at least two key pairs based on the server's public key and its own private key, the client first determines a shared key based on the server's public key and its own private key. The shared key is calculated using a key generation algorithm. As an example, the calculation method for the shared key generated by the client based on the server's public key and its own private key is: (((g^a)mod p)^b)mod p. After calculating the shared key, the client performs derivation processing on the shared key based on a preset key derivation algorithm to obtain at least two key pairs. The preset key derivation algorithm is negotiated between the client and the server, and can be sent by the server to the client in response to a key negotiation request. Optionally, the preset key derivation algorithm can be a key derivation algorithm, such as the HKDF algorithm. By using a preset key derivation algorithm, one or more key pairs with cryptographic strength can be derived from the shared key generated based on the server's private key and the client's public key, while ensuring randomness, thereby ensuring the security of the transmission of the preset login ticket.

[0072] As an optional implementation, the preset key derivation algorithm includes a first preset key derivation algorithm and a second preset key derivation algorithm. When the client performs derivation processing on the shared key based on the preset key derivation algorithm, the client performs key extraction and expansion processing on the shared key based on the first preset key derivation algorithm to obtain the master key. Then, the client performs derivation processing on the master key based on the second preset key derivation algorithm to obtain at least two key pairs. In this implementation, the first preset key derivation algorithm and the second preset key derivation algorithm can be the same or different. Optionally, both the first preset key derivation algorithm and the second preset key derivation algorithm can be the HKDF algorithm. When performing derivation processing on the shared key based on the first preset key derivation algorithm, it can include two processes: an extraction process and an expansion process. The extraction process derives a pseudo-random key that meets cryptographic strength requirements using the shared key. The expansion process uses the pseudo-random key extracted in the extraction process to expand the master key to a specified length while ensuring randomness. When performing derivation processing on the master key based on the second preset key derivation algorithm, the expansion processing method in the HKDF algorithm can be used to expand the master key, thereby obtaining multiple key pairs. By sequentially deriving the shared key using the first and second preset key derivation algorithms, multiple pairs of highly secure key pairs can be obtained. This allows for the separate encryption of multiple preset login tickets, thereby avoiding the global security risk caused by a single point of leakage of preset login tickets.

[0073] S111: The client decrypts the encrypted ticket based on the downlink key in each key pair to obtain the preset login ticket.

[0074] In this embodiment, after obtaining the key pair, the client decrypts the encrypted ticket result based on the downlink key in the key pair to obtain a preset login ticket. Specifically, the key pair obtained by the client is consistent with the key pair generated by the server. The encrypted ticket result may include the encrypted results corresponding to multiple preset login tickets. After obtaining the key pair, the client decrypts the encrypted results corresponding to the multiple preset login tickets sent by the server one by one using the downlink key in the obtained key pair to obtain these preset login tickets. In some embodiments, the encrypted results corresponding to the multiple preset login tickets sent by the server contain a type identifier for each preset login ticket. When decrypting the encrypted ticket result, the client can determine the corresponding key pair based on the type identifier of each preset login ticket, and then use the downlink key in the corresponding key pair to decrypt the encrypted result corresponding to each preset login ticket to obtain all the preset login tickets.

[0075] In some embodiments, the server may first negotiate a key with the client so that both the server and the client obtain multiple key pairs. The server then uses the downlink key in the key pair to encrypt the preset login ticket, obtains the encrypted result, and then sends the encrypted result to the client. The client can use the downlink key in the key pair to decrypt the received encrypted result, thereby obtaining the preset login ticket.

[0076] In this embodiment, after obtaining a preset login ticket, when the client needs to log in to a target business site within a preset business system again, it can quickly log in based on the preset login tickets corresponding to the preset business system and the target business site. When logging in based on the preset login tickets, the client needs to encrypt the preset login ticket using the uplink key in the key pair corresponding to each preset login ticket, and then transmit the encryption result to the server for verification. Specifically, the client sends an access request to the target business site to the server, carrying the encryption result to be verified obtained by encrypting the preset login ticket using the uplink key. The server responds to the access request by decrypting the encryption result to be verified using the uplink key in each key pair, obtaining the preset login ticket. The server then verifies the preset login ticket; if the verification passes, the server executes the client's access operation for the target business site. By setting an uplink key to encrypt the preset login ticket sent by the client to the server, the security of the preset login ticket during uplink transmission is ensured. In addition, by setting uplink and downlink keys to encrypt the transmission of preset login tickets in different transmission directions, the security risks to preset business systems caused by the leakage of a certain key can be reduced.

[0077] In the embodiments of this application, Figure 3 This is a schematic diagram of a login ticket process according to an exemplary embodiment. Figure 2 ,like Figure 3As shown, the client and server negotiate a key agreement to determine the shared key using the X25519 elliptic curve algorithm. The client generates its public and private keys based on the X25519 elliptic curve algorithm; for example, the client generates a random X25519 key pair (pk 1, secret 1). The server generates its public and private keys based on the X25519 elliptic curve algorithm; for example, the server generates a random X25519 key pair (pk 2, secret 2). Optionally, the preset parameters used by the client and server to generate their respective public and private keys can be sent by the server to the client or vice versa. When the client sends a login request to the server, it can include its public key in the request. Upon receiving the login request from the client, the server verifies the login information in the request. If the verification passes, the server generates a preset login ticket corresponding to the client. Optionally, the server can generate multiple preset login tickets for the client. These different preset login tickets serve as login credentials for the client within a preset business system, or as login credentials for different business sites within the preset business system. After generating the preset login ticket for the client, the server can first determine a shared key based on the client's public key and the server's private key. To further ensure the secure transmission of the preset login ticket, the server can perform one or more derivations on the shared key to obtain a key pair with a higher security level. For example... Figure 3As shown, the server derives a master key from the shared key, and then further derives multiple key pairs from the master key. Each key pair contains an uplink key and a downlink key. The uplink key is used to decrypt encrypted data sent from the client to the server, and the downlink key is used to encrypt data sent from the server to the client. Different key pairs are used to encrypt / decrypt different preset login tickets. The server uses the downlink keys from these key pairs to encrypt their respective preset login tickets, thus obtaining the encryption result for each preset ticket. The server then sends the encryption result for each preset ticket, along with its public key, to the client. The server derives key pairs from the master key to encrypt / decrypt different preset login tickets. Different preset login tickets can be used in different scenarios; for example, the key pairs derived by the server from the master key include main_key_up / down, ngn_key_up / down, and web_key_up / down. The `main_key_up / down` directive is used to encrypt / decrypt the default login tickets for the default business system; `ngn_key_up / down` is used to encrypt / decrypt the default login tickets for the default business system based on NGN (Next Generation Network) service sites; and `web_key_up / down` is used to encrypt / decrypt the default login tickets for the default business system based on web (Internet) service sites. After receiving the encryption result for each default ticket and the server's public key, the client first calculates a shared key based on the server's public key and the client's private key. Then, it derives the shared key according to the default key derivation algorithm negotiated with the server during key negotiation, resulting in multiple key pairs. The key pairs obtained by the client are the same as those obtained by the server. Therefore, the client can decrypt the encryption result for each default ticket based on the downlink key in the key pair to obtain the corresponding default login ticket. When a client needs to access a target business site in a preset business system again, it can encrypt the preset login ticket corresponding to the preset business system and the target business site using the uplink key in multiple key pairs, and then send the encryption result to the server. The server decrypts the encryption result using the uplink key in multiple key pairs to obtain the preset login ticket.

[0078] In this embodiment, the server can also set a validity period for the preset login ticket. Furthermore, different validity periods can be set for different preset login tickets; for example, the preset login ticket corresponding to a preset business system can have a longer validity period, while the preset login ticket corresponding to a business site within the preset business system can have a shorter validity period. When the preset login ticket expires, the client needs to re-execute the preset ticket acquisition method described above to obtain the new preset login ticket.

[0079] The login ticket acquisition method described in this application generates multiple parallel key pairs to satisfy the encrypted transmission between different preset login tickets in the case of multi-level parallel client operation and multiple pairs of preset login tickets at the same level operating in parallel. Furthermore, it achieves the function of authenticating preset login tickets through an encryption / decryption negotiation process between the client and the backend when the preset login tickets are not transmitted in plaintext, thereby enhancing the security of the preset login tickets.

[0080] Based on the above description, the following describes a specific embodiment of a login ticket acquisition method according to this application, with the server as the execution subject. Figure 4 This is a flowchart illustrating a login ticket acquisition method with the server as the execution subject, according to an exemplary embodiment. Figure 4 As shown, the method may include:

[0081] S201: In response to a login request sent by a local client, determine at least two preset login tickets; the login request carries the client's public key; the client's public key is generated based on preset parameters negotiated between the client and the local server; the preset login tickets are the client's login credentials in a preset business system or the login credentials of a target business site in the preset business system.

[0082] S203: Generate at least two key pairs based on the server's private key and the client's public key; the server's private key is generated based on preset parameters; each key pair corresponds to a preset login ticket; each key pair includes a downlink key; the downlink key is used to encrypt data sent from the local server to the client.

[0083] S205: Based on the downlink key in the key pair corresponding to each preset login ticket, encrypt each preset login ticket to obtain the ticket encryption result.

[0084] S207: Send the ticket encryption result and the server public key to the client so that the client can obtain at least two key pairs based on the server public key and the client private key, and decrypt the ticket encryption result based on the downlink key in each key pair to obtain the preset login ticket; the server public key and the client private key are generated based on preset parameters.

[0085] In some alternative embodiments, before determining at least two preset login tickets in response to a login request sent by the client, the method further includes:

[0086] In response to a key negotiation request sent by the client, a preset parameter is generated and sent to the client so that the client can generate a client public key and a client private key based on the preset parameter;

[0087] A server public key and a server private key are generated based on preset parameters. The server public key is sent to the client so that the client receives at least two key pairs. The server private key is used to enable the local server to generate at least two key pairs based on the client's public key and the server's private key.

[0088] In some optional embodiments, at least two key pairs are generated based on the server's private key and the client's public key, including:

[0089] Generate a shared key based on the server's private key and the client's public key;

[0090] The shared key is derived based on a preset key derivation algorithm to obtain at least two key pairs; the preset key derivation algorithm is negotiated between the local server and the client.

[0091] In some optional embodiments, the preset key derivation algorithm includes a first preset key derivation algorithm and a second preset key derivation algorithm; the shared key is derivationally processed based on the preset key derivation algorithm to obtain at least two key pairs, including:

[0092] The shared key is extracted and expanded based on the first preset key derivation algorithm to obtain the master key;

[0093] The master key is derived using the second preset key derivation algorithm to obtain at least two key pairs.

[0094] In some optional embodiments, at least two preset login tickets include a first preset login ticket and at least one second preset login ticket; the first preset login ticket is the client's login credential in a preset business system; the second preset login ticket is the client's login credential in a target business site; at least two key pairs include a first key pair and at least one second key pair; the first key pair corresponds to the first preset login ticket, and the second key pair corresponds one-to-one with the second preset login ticket; based on the downlink key in the key pair corresponding to each preset login ticket, each preset login ticket is encrypted to obtain a ticket encryption result, including:

[0095] The first preset login ticket is encrypted using the downlink key in the first key pair to obtain the first encryption result;

[0096] Based on the downlink key in each pair of second key pairs, the second preset login ticket corresponding to each pair of second key pairs is encrypted to obtain the second encryption result;

[0097] The encrypted result of the ticket is obtained based on the first encryption result and the second encryption result.

[0098] In some optional embodiments, each key pair further includes an uplink key; after sending the ticket encryption result and the server's public key to the client, so that the client obtains at least two key pairs based on the server's public key and the client's private key, and so that the client decrypts the ticket encryption result based on the downlink key in each key pair to obtain a preset login ticket, the method further includes:

[0099] Receives an access request from the client to log in to a preset business system; the access request carries an encrypted result to be verified, obtained by encrypting the preset login ticket based on the uplink key;

[0100] The preset login ticket is obtained by decrypting the encryption result to be verified based on the uplink key in each key pair.

[0101] The preset login ticket is validated to obtain the validation result.

[0102] If the verification result is successful, the client will perform access operations for the preset business system.

[0103] Based on the above description, the following describes a specific embodiment of a login ticket acquisition method according to this application, with the client as the execution subject. Figure 5 This is a flowchart illustrating a login ticket acquisition method with a client as the execution subject, according to an exemplary embodiment. Figure 5 As shown, the method may include:

[0104] S301: Send a login request to the local server, so that the server responds to the login request, determines at least two preset login tickets, and generates a key pair corresponding to each preset login ticket based on the server's private key and the client's public key. The server then encrypts each preset login ticket based on the downlink key in the key pair corresponding to each preset login ticket, obtaining the ticket encryption result. The login request carries the client's public key. The client's public key is generated based on preset parameters negotiated between the local client and the server. The preset login ticket is the login credential of the local client in a preset business system or the login credential of the target business site in the preset business system. The server's private key is generated based on preset parameters. Each key pair includes a downlink key. The downlink key is used to encrypt data sent by the server to the local client.

[0105] S303: Receive the encrypted ticket result and the server's public key sent by the server; the server's public key is generated based on preset parameters.

[0106] S305: Obtain at least two key pairs based on the server's public key and the client's private key; the client's private key is generated based on preset parameters.

[0107] S307: Decrypt the encrypted ticket based on the downlink key in each key pair to obtain the preset login ticket.

[0108] In some optional embodiments, the method further includes, before sending a login request to the server:

[0109] Send a key negotiation request to the server so that the server responds to the key negotiation request and generates preset parameters;

[0110] Receive preset parameters sent by the server;

[0111] A client public key and a client private key are generated based on the received preset parameters. The client public key is sent to the server so that the server can generate at least two key pairs based on the client public key. The client private key is used to enable the local client to obtain at least two key pairs based on the server public key and the client private key.

[0112] In some optional embodiments, at least two key pairs are obtained based on the server's public key and the client's private key, including:

[0113] The shared key is determined based on the server's public key and the client's private key;

[0114] The shared key is derived based on a preset key derivation algorithm to obtain at least two key pairs; the preset key derivation algorithm is negotiated between the local client and the server.

[0115] In some optional embodiments, the preset key derivation algorithm includes a first preset key derivation algorithm and a second preset key derivation algorithm; the shared key is derivationally processed based on the preset key derivation algorithm to obtain at least two key pairs, including:

[0116] The shared key is extracted and expanded based on the first preset key derivation algorithm to obtain the master key;

[0117] The master key is derived using the second preset key derivation algorithm to obtain at least two key pairs.

[0118] This application also discloses a login ticket acquisition device. Figure 6 This is a block diagram illustrating a login ticket acquisition device according to an exemplary embodiment. Figure 6 As shown, the device may include at least:

[0119] The preset login ticket determination module 401 is used to determine at least two preset login tickets in response to a login request sent by a local client. The login request carries a client public key. The client public key is generated based on preset parameters negotiated between the client and the local server. The preset login ticket is the client's login credential in a preset business system or the login credential of a target business site in the preset business system.

[0120] The key pair generation module 403 is used to generate at least two key pairs based on the server's private key and the client's public key; the server's private key is generated based on preset parameters; each key pair corresponds to a preset login ticket; each key pair includes a downlink key; the downlink key is used to encrypt data sent from the local server to the client;

[0121] The encryption module 405 is used to encrypt each preset login ticket based on the downlink key in the key pair corresponding to each preset login ticket, and obtain the ticket encryption result;

[0122] The sending module 407 is used to send the ticket encryption result and the server public key to the client, so that the client can obtain at least two key pairs based on the server public key and the client private key, and decrypt the ticket encryption result based on the downlink key in each key pair to obtain a preset login ticket; the server public key and the client private key are generated based on preset parameters.

[0123] In some alternative embodiments, the device further includes:

[0124] The preset parameter generation module is used to generate preset parameters in response to the key negotiation request sent by the client, and send the preset parameters to the client so that the client can generate a client public key and a client private key based on the preset parameters;

[0125] The local server key generation module is used to generate a server public key and a server private key based on preset parameters. The server public key is sent to the client so that the client receives at least two key pairs. The server private key is used to enable the local server to generate at least two key pairs based on the client's public key and the server's private key.

[0126] In some optional embodiments, the key pair generation module includes:

[0127] The shared key generation submodule is used to generate a shared key based on the server's private key and the client's public key;

[0128] The key derivation submodule is used to derive the shared key based on a preset key derivation algorithm to obtain at least two key pairs; the preset key derivation algorithm is negotiated between the local server and the client.

[0129] In some optional embodiments, the preset key derivation algorithm includes a first preset key derivation algorithm and a second preset key derivation algorithm; the key derivation submodule includes:

[0130] The master key determination unit is used to perform key extraction and expansion processing on the shared key based on the first preset key derivation algorithm to obtain the master key.

[0131] A key pair determination unit is used to perform derivative processing on the master key based on a second preset key derivation algorithm to obtain at least two key pairs.

[0132] In some optional embodiments, at least two preset login tickets include a first preset login ticket and at least one second preset login ticket; the first preset login ticket is the client's login credential in a preset business system; the second preset login ticket is the client's login credential in a target business site; at least two key pairs include a first key pair and at least one second key pair; the first key pair corresponds to the first preset login ticket, and the second key pair corresponds one-to-one with the second preset login ticket; the encryption module includes:

[0133] The first encryption result determination unit is used to encrypt the first preset login ticket based on the downlink key in the first key pair to obtain the first encryption result;

[0134] The second encryption result determination unit is used to encrypt the second preset login ticket corresponding to each pair of second key pairs based on the downlink key in each pair of second key pairs, and obtain the second encryption result.

[0135] The bill encryption result determination unit is used to obtain the bill encryption result based on the first encryption result and the second encryption result.

[0136] In some optional embodiments, each key pair further includes an uplink key; the device also includes:

[0137] The access request receiving module is used to receive access requests sent by the client to log in to a preset business system; the access request carries the encryption result to be verified, which is obtained by encrypting the preset login ticket based on the uplink key;

[0138] The decryption module is used to decrypt the encryption result to be verified based on the uplink key in each key pair to obtain the preset login ticket;

[0139] The verification module is used to verify the preset login ticket and obtain the verification result;

[0140] The login module is used to execute client access operations for preset business systems when the verification result is successful.

[0141] It should be noted that the login ticket acquisition device embodiment provided in this application is based on the same inventive concept as the login ticket acquisition method embodiment with the server as the execution subject described above.

[0142] This application also discloses a login ticket acquisition device. Figure 7 This is a block diagram of another login ticket acquisition device according to an exemplary embodiment. Figure 7 As shown, the device may include at least:

[0143] The login request sending module 501 is used to send a login request to the server, so that the server responds to the login request, determines at least two preset login tickets, and generates a key pair corresponding to each preset login ticket based on the server's private key and the client's public key. The server then encrypts each preset login ticket based on the downlink key in the key pair corresponding to each preset login ticket, obtaining the ticket encryption result. The login request carries the client's public key, which is generated based on preset parameters negotiated between the local client and the server. The preset login ticket is the login credential of the local client in a preset business system or the login credential of the target business site in the preset business system. The server's private key is generated based on preset parameters. Each key pair includes a downlink key; the downlink key is used to encrypt data sent by the server to the local client.

[0144] The receiving module 503 is used to receive the encrypted ticket result sent by the server and the server's public key; the server's public key is generated based on preset parameters.

[0145] The key pair determination module 505 is used to obtain at least two key pairs based on the server public key and the client private key; the client private key is generated based on preset parameters.

[0146] The decryption module 507 is used to decrypt the encrypted ticket based on the downlink key in each key pair to obtain the preset login ticket.

[0147] In some alternative embodiments, the device further includes:

[0148] The key negotiation request sending module is used to send a key negotiation request to the server so that the server responds to the key negotiation request and generates preset parameters;

[0149] The preset parameter receiving module is used to receive preset parameters sent by the server.

[0150] The local client key generation module is used to generate a client public key and a client private key based on the received preset parameters. The client public key is sent to the server so that the server can generate at least two key pairs based on the client public key. The client private key is used to enable the local client to obtain at least two key pairs based on the server public key and the client private key.

[0151] In some optional embodiments, the key pair determination module includes:

[0152] The shared key determination submodule is used to determine the shared key based on the server's public key and the client's private key;

[0153] The key derivation submodule is used to derive the shared key based on a preset key derivation algorithm to obtain at least two key pairs; the preset key derivation algorithm is negotiated between the local client and the server.

[0154] In some optional embodiments, the preset key derivation algorithm includes a first preset key derivation algorithm and a second preset key derivation algorithm; the key derivation submodule includes:

[0155] The master key determination unit is used to perform key extraction and expansion processing on the shared key based on the first preset key derivation algorithm to obtain the master key.

[0156] A key pair determination unit is used to perform derivative processing on the master key based on a second preset key derivation algorithm to obtain at least two key pairs.

[0157] It should be noted that the login ticket acquisition device embodiment provided in this application is based on the same inventive concept as the login ticket acquisition method embodiment with the client as the execution subject described above.

[0158] It should be noted that the login ticket acquisition device embodiment provided in this application is based on the same inventive concept as the login ticket acquisition method embodiment described above.

[0159] This application also provides an electronic device for obtaining login tickets. The electronic device includes a processor and a memory. The memory stores at least one instruction or at least one program. The processor loads and executes the at least one instruction or at least one program to implement the login ticket acquisition method provided in any of the above embodiments.

[0160] Embodiments of this application also provide a computer-readable storage medium that can be disposed in a terminal to store at least one instruction or at least one program for implementing a login ticket acquisition method in the method embodiments. The at least one instruction or at least one program is loaded and executed by a processor to implement the login ticket acquisition method provided in the above method embodiments.

[0161] Optionally, in the embodiments of this specification, the storage medium may be located at at least one of the multiple network servers in a computer network. Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0162] The memory described in this specification can be used to store software programs and modules. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory. The memory may primarily include a program storage area and a data storage area. The program storage area may store the operating system, applications required for functions, etc.; the data storage area may store data created based on the use of the device, etc. Furthermore, the memory may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory may also include a memory controller to provide the processor with access to the memory.

[0163] This application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the login ticket acquisition method provided in the above-described method embodiments.

[0164] The login ticket acquisition method provided in this application can be executed on a terminal, computer terminal, server, or similar computing device. Taking running on a server as an example, Figure 8 This is a hardware structure block diagram of a server for a login ticket acquisition method according to an exemplary embodiment. For example... Figure 8As shown, the server 600 can vary significantly due to different configurations or performance. It may include one or more Central Processing Units (CPUs) 610 (CPUs 610 may include, but are not limited to, microprocessors (MCUs) or programmable logic devices (FPGAs), a memory 630 for storing data, and one or more storage media 620 (e.g., one or more mass storage devices) for storing application programs 623 or data 622. The memory 630 and storage media 620 may be temporary or persistent storage. The program stored in the storage media 620 may include one or more modules, each module may include a series of instruction operations on the server. Furthermore, the CPU 610 may be configured to communicate with the storage media 620 and execute the series of instruction operations stored in the storage media 620 on the server 600. Server 600 may also include one or more power supplies 660, one or more wired or wireless network interfaces 650, one or more input / output interfaces 640, and / or one or more operating systems 621, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0165] The input / output interface 640 can be used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of server 600. In one example, the input / output interface 640 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the input / output interface 640 may be a radio frequency (RF) module for wireless communication with the Internet.

[0166] Those skilled in the art will understand that Figure 8 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, server 600 may also include... Figure 8 The more or fewer components shown, or having the same Figure 8 The different configurations shown.

[0167] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, specific embodiments have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0168] The various embodiments in this specification are described 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. In particular, the device and server embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0169] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware, or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0170] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for obtaining login tickets, characterized in that, The method includes: In response to a login request sent by a client, at least two preset login tickets are determined; the login request carries a client public key; the client public key is generated based on preset parameters negotiated between the client and the local server; the preset login ticket is the client's login credential in a preset business system or the login credential of a target business site in the preset business system. At least two key pairs are generated based on the server's private key and the client's public key; the server's private key is generated based on the preset parameters; each key pair corresponds to a preset login ticket; each key pair includes a downlink key; the downlink key is used to encrypt data sent from the local server to the client; Based on the downlink key in the key pair corresponding to each preset login ticket, each preset login ticket is encrypted to obtain the ticket encryption result; The ticket encryption result and the server public key are sent to the client, so that the client can obtain at least two key pairs based on the server public key and the client private key, and the client can decrypt the ticket encryption result based on the downlink key in each key pair to obtain the preset login ticket; the server public key and the client private key are generated based on the preset parameters.

2. The method according to claim 1, characterized in that, Before determining at least two preset login tickets in response to a login request sent by the client, the method further includes: In response to a key negotiation request sent by the client, the preset parameters are generated and sent to the client so that the client generates the client public key and the client private key based on the preset parameters; The server public key and the server private key are generated based on the preset parameters; the server public key is used to be sent to the client so that the client obtains at least two key pairs; the server private key is used to enable the local server to generate the at least two key pairs based on the client public key and the server private key.

3. The method according to claim 1, characterized in that, The generation of at least two key pairs based on the server's private key and the client's public key includes: A shared key is generated based on the server's private key and the client's public key; The shared key is derived based on a preset key derivation algorithm to obtain at least two key pairs; the preset key derivation algorithm is negotiated between the local server and the client.

4. The method according to claim 3, characterized in that, The preset key derivation algorithm includes a first preset key derivation algorithm and a second preset key derivation algorithm; The step of performing derivative processing on the shared key based on a preset key derivation algorithm to obtain at least two key pairs includes: Based on the first preset key derivation algorithm, the shared key is subjected to key extraction and expansion processing to obtain the master key; The master key is derived based on the second preset key derivation algorithm to obtain at least two key pairs.

5. The method according to claim 1, characterized in that, At least two of the preset login tickets include a first preset login ticket and at least one second preset login ticket; the first preset login ticket is the login credential of the client in the preset business system; The second preset login ticket is the client's login credential in the target business site; The at least two key pairs include a first key pair and at least one second key pair; the first key pair corresponds to the first preset login ticket, and the second key pair corresponds one-to-one with the second preset login ticket; The step of encrypting each preset login ticket based on the downlink key in the key pair corresponding to each preset login ticket to obtain the ticket encryption result includes: The first preset login ticket is encrypted based on the downlink key in the first key pair to obtain a first encryption result; Based on the downlink key in each pair of the second key pairs, the second preset login ticket corresponding to each pair of the second key pairs is encrypted to obtain the second encryption result; The encrypted result of the ticket is obtained based on the first encryption result and the second encryption result.

6. The method according to any one of claims 1 to 5, characterized in that, Each key pair further includes an uplink key; after sending the ticket encryption result and the server public key to the client, so that the client obtains at least two key pairs based on the server public key and the client private key, and so that the client decrypts the ticket encryption result based on the downlink key in each key pair to obtain the preset login ticket, the method further includes: The system receives an access request from the client to log in to the preset business system; the access request carries a verification encryption result obtained by encrypting the preset login ticket based on the uplink key. The encryption result to be verified is decrypted based on the uplink key in each key pair to obtain the preset login ticket; The preset login ticket is verified to obtain the verification result; If the verification result is successful, the client performs the access operation for the preset business system.

7. A method for obtaining a login ticket, characterized in that, The method includes: A login request is sent to the server, causing the server to respond to the login request, determine at least two preset login tickets, and generate a key pair corresponding to each preset login ticket based on the server's private key and the client's public key. The server then encrypts each preset login ticket based on the downlink key in the key pair corresponding to each preset login ticket, obtaining a ticket encryption result. The login request carries the client's public key, which is generated based on preset parameters negotiated between the local client and the server. The preset login ticket is the login credential of the local client in a preset business system or the login credential of a target business site in the preset business system. The server's private key is generated based on the preset parameters. Each key pair includes a downlink key, which is used to encrypt data sent by the server to the local client. The system receives the encrypted ticket result and sends the server's public key; the server's public key is generated based on the preset parameters. At least two key pairs are obtained based on the server public key and the client private key; the client private key is generated based on the preset parameters. The ticket encryption result is decrypted based on the downlink key in each key pair to obtain the preset login ticket.

8. The method according to claim 7, characterized in that, Before sending the login request to the server, the method further includes: Send a key negotiation request to the server so that the server responds to the key negotiation request and generates the preset parameters; Receive the preset parameters sent by the server; The client public key and the client private key are generated based on the received preset parameters; the client public key is sent to the server so that the server generates at least two key pairs based on the client public key; the client private key is used to enable the local client to obtain at least two key pairs based on the server public key and the client private key.

9. The method according to claim 7 or 8, characterized in that, The process of obtaining at least two key pairs based on the server public key and the client private key includes: A shared key is determined based on the server's public key and the client's private key; The shared key is derived based on a preset key derivation algorithm to obtain at least two key pairs; the preset key derivation algorithm is negotiated between the local client and the server.

10. The method according to claim 9, characterized in that, The preset key derivation algorithm includes a first preset key derivation algorithm and a second preset key derivation algorithm; The process of deriving the shared key based on the preset key derivation algorithm to obtain at least two key pairs includes: Based on the first preset key derivation algorithm, the shared key is subjected to key extraction and expansion processing to obtain the master key; The master key is derived based on the second preset key derivation algorithm to obtain at least two key pairs.

11. A login ticket acquisition device, characterized in that, The device includes: A preset login ticket determination module is used to determine at least two preset login tickets in response to a login request sent by a client; the login request carries a client public key; the client public key is generated based on preset parameters negotiated between the client and the local server; the preset login ticket is the client's login credential in a preset business system or the login credential of a target business site in the preset business system. A key pair generation module is used to generate at least two key pairs based on the server's private key and the client's public key; the server's private key is generated based on the preset parameters; each key pair corresponds to a preset login ticket; each key pair includes a downlink key; the downlink key is used to encrypt data sent from the local server to the client; The encryption module is used to encrypt each preset login ticket based on the downlink key in the key pair corresponding to each preset login ticket, and obtain the ticket encryption result; The sending module is used to send the ticket encryption result and the server public key to the client, so that the client can obtain at least two key pairs based on the server public key and the client private key, and decrypt the ticket encryption result based on the downlink key in each key pair to obtain the preset login ticket; the server public key and the client private key are generated based on the preset parameters.

12. A login ticket acquisition device, characterized in that, The device includes: A login request sending module is used to send a login request to a local server, so that the server responds to the login request, determines at least two preset login tickets, and generates a key pair corresponding to each preset login ticket based on the server's private key and the client's public key. The server then encrypts each preset login ticket based on the downlink key in the key pair corresponding to each preset login ticket, obtaining a ticket encryption result. The login request carries the client's public key, which is generated based on preset parameters negotiated between the local client and the server. The preset login ticket is the login credential of the local client in a preset business system or the login credential of a target business site in the preset business system. The server's private key is generated based on the preset parameters. Each key pair includes a downlink key, which is used to encrypt data sent by the server to the local client. The receiving module is used to receive the ticket encryption result and the server public key sent by the server; the server public key is generated based on the preset parameters; The key pair determination module is used to obtain at least two key pairs based on the server public key and the client private key; the client private key is generated based on the preset parameters. The decryption module is used to decrypt the ticket encryption result based on the downlink key in each key pair to obtain the preset login ticket.

13. An electronic device for obtaining login tickets, characterized in that, The device includes a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor as described in any one of claims 1-6 or as described in any one of claims 7-10.

14. A computer-readable storage medium, characterized in that, The storage medium stores at least one instruction or at least one program, which is loaded and executed by a processor to implement the login ticket acquisition method as described in any one of claims 1-6 or as described in any one of claims 7-10.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the login ticket acquisition method as described in any one of claims 1-6 or the login ticket acquisition method as described in any one of claims 7-10.

Images