CN111193695A - Encryption method and device for third party account login and storage medium - Google Patents

Encryption method and device for third party account login and storage medium Download PDF

Info

Publication number
CN111193695A
CN111193695A CN201910683098.8A CN201910683098A CN111193695A CN 111193695 A CN111193695 A CN 111193695A CN 201910683098 A CN201910683098 A CN 201910683098A CN 111193695 A CN111193695 A CN 111193695A
Authority
CN
China
Prior art keywords
key
client
public key
server
party account
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201910683098.8A
Other languages
Chinese (zh)
Other versions
CN111193695B (en
Inventor
刘亚运
王维富
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN201910683098.8A priority Critical patent/CN111193695B/en
Publication of CN111193695A publication Critical patent/CN111193695A/en
Application granted granted Critical
Publication of CN111193695B publication Critical patent/CN111193695B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

The embodiment of the invention discloses an encryption method, an encryption device and a storage medium for third party account login. When the third-party account login is detected, third-party account data are obtained, a client-side private key and a client-side public key are generated, the client-side public key is sent to a key management service, the key management service generates a server-side private key and a server-side public key according to the client-side public key, the server-side public key is returned to the client side, the legality of the server-side public key is verified, when the legality verification of the server-side public key is confirmed to be passed, a first symmetric key is generated according to the server-side public key and the client-side private key, and the third-party account data are encrypted according to the first symmetric key. According to the embodiment of the application, the whole key negotiation process can be completed only by newly adding the network round-trip delay once, and the user key is isolated, so that the safety of service login data is effectively improved when a third-party account is logged in.

Description

Encryption method and device for third party account login and storage medium
Technical Field
The invention relates to the technical field of communication, in particular to an encryption method and device for third party account login and a storage medium.
Background
With the continuous popularization and development of terminals, users increasingly rely on the terminals, and various applications can be installed on the terminals, wherein the instant messaging application is widely used, and the users can complete communication and interaction with friends through the instant messaging application.
In the prior art, for a mobile terminal application with an account system, an external third-party social account is often supported for registration and login, such as WeChat, QQ, microblog login and the like. They often integrate third party SDKs for access to call in exchange for the logged on access _ token ticket. The SDK encapsulates the interface details for obtaining the access _ token, and the safety of login information is ensured. After the terminal gets the access _ token login bill, the terminal sends a login request to the service background, and the service background needs to verify the validity of the third-party access _ token bill, so as to perform subsequent service processing.
In the research and practice process of the prior art, the inventor of the present invention finds that, in the prior art, when a terminal initiates a login request to a service background, if the security of a communication link is not high, the access _ token may be intercepted by a broker, which may cause the leakage of authentication information of a third party and a security risk.
Disclosure of Invention
The embodiment of the invention provides an encryption method, device and storage medium for third party account login, aiming at improving the security of service login data when the third party account is logged in.
In order to solve the above technical problems, embodiments of the present invention provide the following technical solutions:
an encryption method for third party account login comprises the following steps:
when the third party account login is detected, acquiring the third party account data, and generating a client private key and a client public key based on a first preset algorithm;
sending the client public key to a key management service so that the key management service generates a server private key and a server public key according to the client public key based on the first preset algorithm, and returns the server public key to the client;
verifying the validity of the server public key;
and when the validity verification of the server public key is confirmed to pass, generating a first symmetric key according to the server public key and a client private key, and encrypting the third party account data according to the first symmetric key based on a second preset algorithm.
An encryption device for third party account login comprises:
the first generation unit is used for acquiring third party account data when the third party account login is detected, and generating a client private key and a client public key based on a first preset algorithm;
the first sending unit is used for sending the client public key to a key management service so that the key management service generates a server private key and a server public key according to the client public key based on the first preset algorithm and returns the server public key to the client;
the verifying unit is used for verifying the validity of the server public key;
and the encryption unit is used for generating a first symmetric key according to the server public key and the client private key when the verification unit passes the verification, and encrypting the third party account data according to the first symmetric key based on a second preset algorithm.
In some embodiments, the apparatus further comprises:
the version obtaining unit is used for obtaining the version information of the client by the key management service before the client logs in the third party account;
and the second generation unit is used for generating a preset public key and a preset private key according to the version information based on the third preset algorithm, and the key management service stores the preset private key and sends the preset public key to the client.
In some embodiments, the key management service signs the server public key through the preset private key and then returns the server public key to the client, and the verification unit is specifically configured to verify the validity of the signature of the server public key through the preset public key.
In some embodiments, after the key management service generates a server private key and a server public key, the key management service generates a second symmetric key from the server private key and a client public key, the apparatus further comprising:
the second sending unit is used for sending the encrypted third party account data to a login service after the encryption unit encrypts the third party account data according to the first symmetric key based on a second preset algorithm;
a key obtaining unit, configured to control the login service to obtain the second symmetric key from the key management service;
and the decryption unit is used for controlling the login service to decrypt the encrypted third party account data based on the second symmetric key so as to generate the third party account data.
A storage medium stores a plurality of instructions, and the instructions are suitable for being loaded by a processor to execute the steps in the encryption method for third party account login.
According to the embodiment, when the third-party account login is detected, third-party account data are obtained, a client-side private key and a client-side public key are generated based on a first preset algorithm, the client-side public key is sent to a key management service, the key management service generates a server-side private key and a server-side public key according to the client-side public key based on the first preset algorithm, the server-side public key is returned to the client side, the legality of the server-side public key is verified, when the validity verification of the server-side public key is confirmed to be passed, a first symmetric key is generated according to the server-side public key and the client-side private key, and the third-party account data are encrypted according to the first symmetric key based on a second preset. According to the embodiment of the application, the whole key negotiation process can be completed only by newly adding the network round-trip delay once, and the user key is isolated, so that the safety of service login data is effectively improved when a third-party account is logged in.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
Fig. 1 is a schematic view of a scenario of an encryption system for third party account login according to an embodiment of the present invention;
fig. 2 is a schematic flowchart of an encryption method for third party account login according to an embodiment of the present invention;
fig. 3 is another schematic flowchart of an encryption method for third party account login according to an embodiment of the present invention;
fig. 4 is a schematic diagram of a login interface according to an embodiment of the present application;
fig. 5 is a schematic flowchart of another encryption method for third party account login according to the embodiment of the present application;
fig. 6 is a schematic structural diagram of an encryption apparatus for third party account login according to an embodiment of the present invention;
fig. 7 is a schematic structural diagram of an encryption apparatus for third party account login according to an embodiment of the present invention;
fig. 8 is a schematic structural diagram of a terminal according to an embodiment of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the invention. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is explicitly and implicitly understood by one skilled in the art that the embodiments described herein can be combined with other embodiments.
The embodiment of the present invention provides a method for detecting a file version of a third party library, where an execution main body of the method for detecting a file version of a third party library may be a device for detecting a file version of a third party library provided in the embodiment of the present invention, or a server integrated with the device for detecting a file version of a third party library, where the device for detecting a file version of a third party library may be implemented in a hardware or software manner.
Before describing the technical solution of the present invention, the related technical terms are briefly explained:
serialization: serialization (Serialization) is the process of converting state information of an object into a form that can be stored or transmitted. During serialization, the object writes its current state to a temporary or persistent store. The object may later be recreated by reading or deserializing the state of the object from storage.
And (3) secret key: the cipher used to encrypt the plaintext is the same key that is used to encrypt and decrypt the plaintext in a symmetric encryption algorithm. The two communication parties can calculate the same encryption key through a negotiation mechanism.
ECDH: ECDH is DH (Diffie-Hellman) key exchange algorithm based on ECC (Elliptic Curve cryptosystem, see ECC). Both parties of the exchange can negotiate a key without sharing any secrets.
ECDSA: the Elliptic Curve Digital Signature Algorithm (Elliptic Curve Digital Signature Algorithm) is a simulation of a Digital Signature Algorithm (DSA) by using an Elliptic Curve, is used for Digital Signature, and is a combination of ECC and DSA, and the Algorithm adopted in the Signature is ECC.
AES-GCM: AES is a symmetric encryption algorithm where GCM (Galois/Counter Mode) means that the symmetric encryption uses Counter Mode with GMAC message authentication code.
refresh _ token: the long bill is used for refreshing the verification authentication bill, and the validity period is long.
access _ token: and the short bill is used for verifying the legality of the user identity. The validity period of the ticket is short, and the refresh token needs to be periodically exchanged for a new access token.
The embodiment of the invention provides an encryption method and device for third party account login and a storage medium.
Referring to fig. 1, fig. 1 is a schematic view of a scenario of an encryption system for third party account login provided in the embodiment of the present invention, including: the terminal 10 and the server 20 may be connected through a communication network, and the communication network may include a wireless network and a wired network, wherein the wireless network includes one or more of a wireless wide area network, a wireless local area network, a wireless metropolitan area network, and a wireless personal area network. The network includes network entities such as routers, gateways, etc., which are not shown in the figure. The terminal 10 may interact with the server 20 via a communication network, for example, by downloading an application (e.g., an instant messaging application) from the server 20.
The encryption system for third party account login may include an encryption device for third party account login, and the encryption device for third party account login may be specifically integrated in a terminal having computing capability and provided with a storage unit and a microprocessor, such as a tablet computer, a mobile phone, a notebook computer, a desktop computer, and the like, in fig. 1, the terminal is the terminal 10 in fig. 1, and various applications required by a user, such as an instant messaging application having an information interaction function, may be installed in the terminal 10. The terminal 10 may be configured to acquire third party account data, send the third party account data to the server 20, and receive account association information, such as a nickname of a head portrait, a mobile phone number, and private information of a work place, returned by the server 20 according to the third party account data, and the terminal 10 displays the received account association information to the user.
The encryption system for third party account login may further include a server 20, which is mainly configured to receive third party account data sent by the terminal 10, perform authentication according to the third party account data, confirm the identity of the user, obtain account association information after confirmation, and send the account association information to the terminal 10. The encryption system for third party account login may further include a memory configured to store an information base, where the information base includes an association relationship between the third party account data and the account association information, so that the server may obtain the third party account data and the account association information associated with the third party account data from the memory and send the third party account data and the account association information to the terminal 10.
It should be noted that the schematic view of the scenario of the encryption system for third party account login shown in fig. 1 is merely an example, and the encryption system for third party account login and the scenario described in the embodiment of the present invention are for more clearly illustrating the technical solution of the embodiment of the present invention, and do not limit the technical solution provided in the embodiment of the present invention.
The following are detailed below. The numbers in the following examples are not intended to limit the order of preference of the examples.
In this embodiment, a description will be given of an encryption device for third party account login, which may be specifically integrated in a terminal having computing capability with a storage unit and a processor installed therein.
An encryption method for third party account login comprises the following steps:
when the third party account login is detected, acquiring the third party account data, and generating a client private key and a client public key based on a first preset algorithm;
sending the client public key to a key management service so that the key management service generates a server private key and a server public key according to the client public key based on the first preset algorithm, and returns the server public key to the client;
verifying the validity of the server public key;
and when the validity verification of the server public key is confirmed to pass, generating a first symmetric key according to the server public key and a client private key, and encrypting the third party account data according to the first symmetric key based on a second preset algorithm.
Referring to fig. 2, fig. 2 is a flowchart illustrating an encryption method for third party account login according to an embodiment of the present invention. The encryption method for third party account login comprises the following steps:
in step 101, when it is detected that a third party account logs in, third party account data is acquired, and a client private key and a client public key are generated based on a first preset algorithm.
Among the existing clients with account systems, in order to facilitate user login, external third-party social accounts are often supported for registration and login, and third-party SDKs are often integrated for access parties to call in exchange for logged-in access _ token bills. The SDK is a software development kit, which is a collection of development tools used by software engineers to create application software for a specific software package, a software framework, a hardware platform, an operating system, and the like, and generally, the SDK is an SDK used for developing an application program on a Windows platform. It may simply be a file that provides an application program interface API for a certain programming language, but may also include complex hardware that can communicate with a certain embedded system. The SDK encapsulates the interface details for obtaining the access _ token, and the safety of login information is ensured.
In one embodiment, when it is detected that the user performs third party account login, for example, clicking other login modes on an application login page, and then selecting one click login from a plurality of third party login options, in the process, in order to ensure the security of a communication link, two modes are attempted to establish communication. The scheme is that a safe data path is established by using HTTPS, and the data link of a user is ensured by a TLS layer (a safe transport layer protocol). And the second scheme is to adopt a private TLV type protocol, such as ProtoBuf and the like, to serialize the request of the user and transmit the plaintext to the server for processing. Specifically, when the client clicks the third-party account to log in, the corresponding SDK is pulled up, and the user returns the access _ token of the time to the client after authorization. The client uses the access _ token and the related service information, serializes the information through the protobuffer, and then sends the serialized information to the login service. And after the login service deserialization request packet is sent, the access _ token is sent to the third-party authentication server. After the legality of the user is authenticated, the third-party server returns relevant information of the user, such as private information of a head portrait nickname, a mobile phone number, a work place and the like, according to the authorization level of the application. The login service serializes the information and returns the serialized information to the client, and the client correspondingly displays the information.
For the first scheme, a TLS layer is introduced to ensure the security of data communication links at the front end and the back end. In the aspect of operation and maintenance, a CA certificate needs to be applied for and purchased for maintenance; in the aspect of service development, both the front end and the back end are required to support the HTTPS function, the development workload of the service side is large, service failure is easily caused due to certificate-related problems, and in service interaction, because key negotiation of TLS needs to be exchanged for many times, interaction delay of the front end and the back end and loss of computing resources are increased. For the second scheme, a private request protocol is adopted to serialize data. However, if the protocol format is cracked, the man-in-the-middle can easily acquire the third party login bill information of the user, so that the third party login bill information masquerades as a server, all account requests of the user are hijacked, and sensitive information of the user is leaked.
In the embodiment of the application, when the third-party account login is detected, the corresponding SDK is pulled up, and the user returns the short-ticket data access _ token of the time to the client after authorization, wherein the short-ticket data access _ token may also be long-ticket data refresh _ token.
Further, a client private key and a client public key are generated based on a first preset algorithm. The first preset algorithm may be an ECDH algorithm. The ECDH algorithm is mainly used to establish secure common encrypted data in an insecure channel, and generally, a private key is exchanged, and the private key is generally used as a symmetric encryption key to be used by two parties in subsequent data transmission. For example, a pair of local public and private keys, a client _ pub _ key and a client _ pri _ key are generated locally through an ECDH algorithm, where the client _ pub _ key is a client public key and the client _ pri _ key is a client private key.
In step 102, the client public key is sent to the key management service, so that the key management service generates a server private key and a server public key according to the client public key based on a first preset algorithm, and returns the server public key to the client.
In the embodiment of the application, compared with the prior art, a new key management service is added, the client sends the client public key to the key management service, and the key management service can be a server or a cloud server and is used for exchanging the user key during each login.
In an embodiment, the key management service receives a client public key, such as a client _ pub _ key, sent by a client, and generates a server private key and a server public key according to the client public key by using the first preset algorithm, such as through an ECDH algorithm, svr _ pub _ key and svr _ pri _ key, where svr _ pub _ key is the server public key, and svr _ pri _ key is the server private key, and then returns the server private key, that is, svr _ pri _ key, to the client in clear text.
In step 103, the validity of the server public key is verified.
In an embodiment of the application, the validity of the public key of the server can be verified through a preset pair of public and private keys. For example, a preset public key is set in the client, a preset private key is set in the key management service, then the key management service signs the server public key through the preset private key to generate a corresponding information digest while sending the server public key plaintext to the client, and then the key management service returns the information digest and the server public key plaintext to the client.
Further, after receiving the loopback packet of the key management service, the client checks whether the signature of the information digest in the loopback packet is legal or not through a preset public key stored in the client, specifically, checks whether the signature is issued by the corresponding key management service or not, because the preset public key is stored in the client and the preset private key is stored in the key management service, the preset private key is only known by a real background service, that is, the key management service, and if the verification is successful, the validity of the server public key is verified to be passed, that is, the received server public key is legal, so that the next operation can be executed.
In an embodiment, the preset pair of public and private keys may be pre-generated by a key management service, for example, the key management service may generate a pair of public and private keys by using an ECDSA algorithm according to a version number of a client, and pre-set the public key in the client, which may be referred to as a verify _ key; and the private key is stored in a key management service, which may be referred to as sign _ key. That is, before the client logs in the third party account, the method further includes:
the key management service acquires version information of the client;
generating a preset public key and a preset private key according to the version information based on the third preset algorithm;
and the key management service stores the preset private key and sends the preset public key to the client.
In an embodiment, in the process that the key management service returns the server public key to the client, the server public key may be signed by a preset private key, and the specific process includes: the key management service uses a preset sign _ key to sign the generated svr _ pub _ key to generate a corresponding information digest, wherein the signature is ECDSA (sign _ key, client _ rand). And transmitting the signature digest of the background server and the corresponding svr _ pub _ key plaintext back to the corresponding client. That is, the step of returning the server public key to the client includes:
and the server public key is signed by the preset private key and then returned to the client.
In an embodiment, when the client verifies the validity of the server public key, the preset public key may be used to verify whether the signature of the information digest in the packet is valid, and the specific process may be as follows: after receiving the return packet of the key management service, the client checks whether the signature of the return packet is issued by the real key management service through a preset verify _ key. Since the sign _ key is only known by the real background service, that is, the key management service, if the check is successful, it indicates that the svr _ pub _ key acquired this time is legal. Namely, the step of verifying the validity of the server public key includes:
and verifying the validity of the signature of the server public key through the preset public key.
In step 104, when it is determined that the validity of the server public key passes the verification, a first symmetric key is generated according to the server public key and the client private key, and third party account data is encrypted according to the first symmetric key based on a second preset algorithm.
In an embodiment, for example, when the client successfully verifies the signature through the preset verify _ key, it indicates that svr _ pub _ key obtained this time is legal, and a corresponding symmetric key may also be generated locally at the client, and specifically, a first symmetric key may be generated according to a public key of the server and a private key of the client, where the first symmetric key is, for example, share _ key ECDH _ general (client _ pri _ key, svr _ pub _ key), and the first symmetric key is used to encrypt the third-party account data. The symmetric key is also called private key encryption, belongs to a symmetric cryptosystem, and means that two parties use the same key for encryption and decryption. That is, both the sending and receiving parties must use the same key to encrypt and decrypt the plaintext.
Further, after the client generates the first symmetric key, the third party account data may be encrypted according to the first symmetric key based on a second preset algorithm. The second predetermined algorithm may be a symmetric encryption algorithm, which may include a DES algorithm, a 3DES algorithm, a TDEA algorithm, a Blowfish algorithm, an RC5 algorithm, an IDEA algorithm, an AES-GCM algorithm, and the like, and in an embodiment, the third party account data may be encrypted using the AES-GCM algorithm. G in GCM means GMAC and C means CTR. The GCM may provide encryption and integrity check of the message, and in addition, it may provide integrity check of the additional message AES-GCM algorithm is an algorithm with authentication and encryption, and may generate encrypted data and an authentication code for a given original text. The parameters are as follows: the method comprises the steps of encrypting original text, storing encrypted ciphertext, an IV vector, a generated message verification code tag and extra message authentication data aad, and the two communication parties need to share the encrypted original text, the encrypted ciphertext, the IV vector and the extra message authentication data aad.
Further, in the symmetric encryption algorithm of the embodiment of the present application, a data sender, that is, a client, processes a plaintext (original data) and an encryption key together through a special encryption algorithm, and then changes the plaintext into a complex encryption ciphertext to send out. After the receiver receives the ciphertext, if the receiver wants to decode the original text, the receiver needs to decrypt the ciphertext by using the key used for encryption and the inverse algorithm of the same algorithm so as to recover the ciphertext into readable plaintext. In the symmetric encryption algorithm, only one key is used, and both the sender and the receiver use the key to encrypt and decrypt data, so that the encryption key must be known by a secret party in advance. Therefore, in an embodiment, after the key management service receives the client public key and generates the server public key and the server private key based on the first preset algorithm according to the client public key, a second symmetric key may be generated according to the client public key and the server private key and stored in the key management service, so as to decrypt the third-party account data encrypted by the first symmetric key.
In one embodiment, symmetric encryption refers to an encryption algorithm that uses the same key for encryption and decryption. That is, the encryption key can be derived from the decryption key, and the decryption key can also be derived from the encryption key. In most symmetric algorithms, the encryption key and the decryption key are the same, so the first symmetric key in the client and the second symmetric key in the key management service may be the same. The third party account data is encrypted by the first symmetric key of the client and then sent to the login service, and after receiving the encrypted third party account data, the login service requests to acquire the second symmetric key from the key management service, so that the decryption of the third party account data is completed, the request of a user is decrypted, the plaintext service data is acquired, and the login of the third party account is completed.
In the above whole interaction flow, before logging in each time, the client needs to exchange the public key of the server for one session with the key management service to uniquely generate the symmetric key of each session. Each exchange of each client generates a pair of unique public and private keys, and each calculated symmetric key is also session unique, so that the account login security of all users cannot be influenced due to key leakage.
In the above embodiment, since the protocol during key agreement is unencrypted, in order to prevent hijacking and tampering by a man in the middle, the server side key of the key management service is signed by using a preset private key during repackaging by the key management service. After receiving the reply packet, the client can verify the signature data by using a preset public key, and if the verification is successful, the third-party account data can be encrypted.
As can be seen from the above, the encryption method for third party account login provided in the embodiment of the present application may obtain third party account data when it is detected that third party account login is performed, generate a client private key and a client public key based on a first preset algorithm, and send the client public key to the key management service, so that the key management service generates a server private key and a server public key according to the client public key based on the first preset algorithm, returns the server public key to the client, verifies the validity of the server public key, generates a first symmetric key according to the server public key and the client private key when it is determined that the validity verification of the server public key passes, and encrypts the third party account data according to the first symmetric key based on a second preset algorithm. According to the embodiment of the application, the whole key negotiation process can be completed only by newly adding the network round-trip delay once, and the user key is isolated, so that the safety of service login data is effectively improved when a third-party account is logged in.
The following describes in further detail an example of the encryption method for third party account login according to the above embodiment.
In this embodiment, an example will be described in which the encryption device for the third party account login is specifically integrated in the terminal.
Referring to fig. 3, fig. 3 is another schematic flow chart of an encryption method for third party account login according to an embodiment of the present invention. The method flow can comprise the following steps:
step 201, when it is detected that a third party account logs in, obtaining third party account data, and generating a client private key and a client public key based on a first preset algorithm.
In an embodiment, a user may log in an account in an application to obtain account data, and for some users who use the application for the first time, to avoid a complicated step of registering the account, a third-party account may be selected for logging in, for example, an integrated third-party SDK for an access party to call in exchange for a logged-in access _ token ticket.
In an embodiment, as shown in fig. 4, fig. 4 is a schematic view of a login interface provided in the embodiment of the present application, when a user uses a client, the user may select to log in or register on the login interface, and the client may also display types of accounts supporting login, including third-party accounts, such as FaceBook, Line, WeChat, QQ, and the like, for the user to select, and the user may select the type of the account owned by the user to complete the login of the third-party account.
Further, after the user clicks one of the third-party account login modes, for example, the user clicks FaceBook login, the client may further generate prompt information, where the prompt information includes permission, such as location permission, network permission, and the like, of the terminal obtained when the client uses FaceBook to log in, and requests the user whether to continue, and if the user determines to continue logging in, the user jumps to a third-party account login interface to complete login operation.
Referring to fig. 5, fig. 5 is a schematic flowchart of another encryption method for third party account login according to the embodiment of the present application. In an embodiment, when it is detected that the user logs in the third-party account, the corresponding SDK is pulled up, and the user returns the short-ticket data access _ token of the time to the client after authorization, where the short-ticket data access _ token may also be long-ticket data refresh _ token.
Further, a client private key and a client public key are generated based on a first preset algorithm. The first preset algorithm may be an ECDH algorithm. The ECDH algorithm is mainly used to establish secure common encrypted data in an insecure channel, and generally, a private key is exchanged, and the private key is generally used as a symmetric encryption key to be used by two parties in subsequent data transmission. For example, a pair of local public and private keys, a client _ pub _ key and a client _ pri _ key are generated locally through an ECDH algorithm, where the client _ pub _ key is a client public key and the client _ pri _ key is a client private key.
Step 202, sending the client public key to the key management service, so that the key management service generates a server private key and a server public key according to the client public key based on a first preset algorithm, and returns the server public key to the client.
In the embodiment of the application, compared with the prior art, a new key management service is added, the client sends the client public key to the key management service, and the key management service can be a server or a cloud server and is used for exchanging the user key during each login.
Further, after the client generates the client public key and the client private key locally, the client can request a random serial number based on the client public key, and simultaneously acquire the device information corresponding to the terminal and transmit the device information and the client public key to the key management service of the back end. For example, after generating the client _ pub _ key and the client _ pri _ key, the client transmits the client _ pub _ key, the requested random sequence number client _ rand, and the related device information, which are generated this time, to the key management service of the back end.
In an embodiment, the key management service receives a client public key, such as a client _ pub _ key, sent by a client, and generates a server private key and a server public key according to the client public key by using the first preset algorithm, such as through an ECDH algorithm, svr _ pub _ key and svr _ pri _ key, where svr _ pub _ key is the server public key, and svr _ pri _ key is the server private key, and then returns the server private key, that is, svr _ pri _ key, to the client in clear text.
Step 203, the key management service generates a second symmetric key according to the server private key and the client public key.
In an embodiment, the key management service may GENERATE the second symmetric key through an algorithm according to the server-side private key and the client-side public key, for example, the key management service may calculate, according to a symmetric key algorithm, the second symmetric key share _ key (ECDH _ general _ key, svr _ pri _ key) corresponding to the client-side this time. Further, the second symmetric key may be saved in the user device dimension and the usage validity period may be set.
And step 204, verifying the validity of the public key of the server.
In an embodiment of the application, the validity of the public key of the server can be verified through a preset pair of public and private keys. For example, a preset public key is set in the client, a preset private key is set in the key management service, then the key management service signs the server public key through the preset private key to generate a corresponding information digest while sending the server public key plaintext to the client, and then the key management service returns the information digest and the server public key plaintext to the client.
Further, after receiving the loopback packet of the key management service, the client checks whether the signature of the information digest in the loopback packet is legal or not through a preset public key stored in the client, specifically, checks whether the signature is issued by the corresponding key management service or not, because the preset public key is stored in the client and the preset private key is stored in the key management service, the preset private key is only known by a real background service, that is, the key management service, and if the verification is successful, the validity of the server public key is verified to be passed, that is, the received server public key is legal, so that the next operation can be executed.
In an embodiment, the preset pair of public and private keys may be pre-generated by a key management service, for example, the key management service may generate a pair of public and private keys by using an ECDSA algorithm according to a version number of a client, and pre-set the public key in the client, which may be referred to as a verify _ key; and the private key is stored in a key management service, which may be referred to as sign _ key.
In an embodiment, in the process that the key management service returns the server public key to the client, the server public key may be signed by a preset private key, and the specific process includes: the key management service uses a preset sign _ key to sign the generated svr _ pub _ key to generate a corresponding information digest, wherein the signature is ECDSA (sign _ key, client _ rand). And transmitting the signature digest of the background server and the corresponding svr _ pub _ key plaintext back to the corresponding client.
In an embodiment, when the client verifies the validity of the server public key, the preset public key may be used to verify whether the signature of the information digest in the packet is valid, and the specific process may be as follows: after receiving the return packet of the key management service, the client checks whether the signature of the return packet is issued by the real key management service through a preset verify _ key. Since the sign _ key is only known by the real background service, that is, the key management service, if the check is successful, it indicates that the svr _ pub _ key acquired this time is legal.
And step 205, when the validity verification of the server public key is confirmed to pass, generating a first symmetric key according to the server public key and the client private key, and encrypting the third party account data according to the first symmetric key based on a second preset algorithm.
In an embodiment, for example, when the client successfully verifies the signature through the preset verify _ key, it indicates that svr _ pub _ key obtained this time is legal, and a corresponding symmetric key may also be generated locally at the client, and specifically, a first symmetric key may be generated according to a public key of the server and a private key of the client, where the first symmetric key is, for example, share _ key ECDH _ general (svr _ pub _ key). The first symmetric key in the client and the second symmetric key in the key management service may be the same.
Further, after the client generates the first symmetric key, the third party account data may be encrypted according to the first symmetric key based on a second preset algorithm. The second preset algorithm may be an AES-GCM algorithm, and encrypts the data ENC (share _ key, access _ token + user _ data) of the service login request, so as to request a login service with a service background.
In an embodiment, the encrypted third party account data may further carry device information, and is used to send a second key corresponding to the key management service through the device information.
Step 206, the encrypted third party account data is sent to the login service, and the login service acquires the second symmetric key from the key management service and decrypts the second symmetric key based on the second symmetric key to generate the third party account data.
In the embodiment of the present application, symmetric encryption refers to an encryption algorithm that uses the same key for encryption and decryption. That is, the encryption key can be derived from the decryption key, and the decryption key can also be derived from the encryption key. Whereas in most symmetric algorithms the encryption key and decryption key are the same. That is, the third party account data encrypted by the first symmetric key of the client can be decrypted by the second symmetric key in the key management service.
In one embodiment, the step of the login service obtaining the second symmetric key from the key management service includes:
and the login service acquires the second symmetric key from the key management service according to the equipment information.
For example, after receiving the request, the login service queries the share _ key corresponding to the device from the key management service according to the device information of the user, decrypts the request of the user, and obtains the plaintext service data.
Step 207, the login service sends the third party account data to the third party authentication server to complete the login.
In an embodiment, the third party authentication server verifies the validity of the user identity according to the third party account data, and if the user identity is confirmed to be valid, the third party authentication server obtains the associated information of the user and sends the associated information to the login service, so that the login service returns the associated information to the client, and the client displays the associated information. The associated information of the user is, for example, private information such as a head portrait nickname, a mobile phone number, a work place, and the like.
In one embodiment, the key management service generates a pair of public and private keys by using an ECDSA algorithm according to the version number of the client, and presets the public key in the client, which is called a verify _ key; the private key is stored in a key management service, called sign _ key. Meanwhile, a pair of spare public keys and private keys can be generated, for example, default _ svr _ pub _ key and default _ svr _ pri _ key, where default _ svr _ pub _ key is a used public key, default _ svr _ pri _ key is a spare private key, default _ svr _ pub _ key is preset in the client, default _ svr _ pri _ key is stored in the key management service, and the preset server private key is updated and replaced along with the version of the client, so that the leaked security risk can be reduced. That is, before the client logs in the third party account, the method further includes:
and the key management service generates a spare public key and a spare private key, stores the spare private key and sends the spare public key to the client.
In an embodiment, a protocol during key agreement is unencrypted, and in order to prevent hijacking and tampering by a man in the middle, the server uses a preset sign _ key to sign svr _ pub _ key of the server during package return. After receiving the package, the client can check the signature data by using a preset verify _ key, and if the check fails, the data is considered to be possibly tampered, and a preset default _ svr _ pub _ key is used for calculating a symmetric key. That is, after the insufficiency of verifying the validity of the server public key, the method further includes:
and when the validity verification of the server public key is not passed, generating a third symmetric key according to the standby public key and a client private key, and encrypting the third party account data according to the third symmetric key based on a second preset algorithm.
Further, after the client encrypts the third symmetric key, the key management service may also calculate a fourth symmetric key by using the spare private key, where the fourth symmetric key is used to decrypt the encrypted third-party account data.
In the above whole interaction flow, before logging in each time, the client needs to exchange the public key of the server for one session with the key management service to uniquely generate the symmetric key of each session. Each exchange of each client generates a pair of unique public and private keys, and each calculated symmetric key is also session unique, so that the account login security of all users cannot be influenced due to key leakage.
In the above embodiment, since the protocol during key agreement is unencrypted, in order to prevent hijacking and tampering by a man in the middle, the server side key of the key management service is signed by using a preset private key during repackaging by the key management service. After receiving the reply packet, the client can verify the signature data by using a preset public key, and if the verification is successful, the third-party account data can be encrypted. If the verification fails, the data is considered to be possibly tampered, and a preset spare public key is used for calculating the symmetric encryption key.
As can be seen from the above, the encryption method for third party account login provided in this embodiment of the present application may obtain third party account data when it is detected that third party account login is performed, generate a client private key and a client public key based on a first preset algorithm, send the client public key to the key management service, so that the key management service generates a server private key and a server public key according to the client public key based on the first preset algorithm, return the server public key to the client, the key management service generates a second symmetric key according to the server private key and the client public key, verify the legitimacy of the server public key, when it is determined that the validity verification of the server public key passes, generate a first symmetric key according to the server public key and the client private key, encrypt the third party account data according to the first symmetric key based on the second preset algorithm, send the encrypted third party account data to the login service, and the login service acquires the second symmetric key from the key management service, decrypts the second symmetric key based on the second symmetric key to generate third-party account data, and sends the third-party account data to the third-party authentication server to complete login. According to the embodiment of the application, the whole key negotiation process can be completed only by newly adding the network round-trip delay once, and the user key is isolated, so that the safety of service login data is effectively improved when a third-party account is logged in.
In order to better implement the encryption method for third party account login provided by the embodiment of the invention, the embodiment of the invention also provides a device for the encryption method based on third party account login. The meaning of the noun is the same as that in the encryption method for third party account login, and specific implementation details can refer to the description in the method embodiment.
Referring to fig. 6, fig. 6 is a schematic structural diagram of an encryption apparatus for third party account login according to an embodiment of the present invention. The encryption device for logging in by the third party account may include:
the first generating unit 301 is configured to, when it is detected that a third party account logs in, obtain third party account data, and generate a client private key and a client public key based on a first preset algorithm.
Among the existing clients with account systems, in order to facilitate user login, external third-party social accounts are often supported for registration and login, and third-party SDKs are often integrated for access parties to call in exchange for logged-in access _ token bills.
In an embodiment, when the third-party account login is detected, the corresponding SDK is pulled up, and the user returns the short ticket data access _ token of the time to the client after authorization, where the short ticket data access _ token may also be the long ticket data refresh _ token.
Further, the first generating unit 301 generates a client private key and a client public key based on a first preset algorithm. The first preset algorithm may be an ECDH algorithm. The ECDH algorithm is mainly used to establish secure common encrypted data in an insecure channel, and generally, a private key is exchanged, and the private key is generally used as a symmetric encryption key to be used by two parties in subsequent data transmission. For example, a pair of local public and private keys, a client _ pub _ key and a client _ pri _ key are generated locally through an ECDH algorithm, where the client _ pub _ key is a client public key and the client _ pri _ key is a client private key.
A first sending unit 302, configured to send the client public key to a key management service, so that the key management service generates a server private key and a server public key according to the client public key based on the first preset algorithm, and returns the server public key to the client.
In the embodiment of the application, compared with the prior art, a new key management service is added, the client sends the client public key to the key management service, and the key management service can be a server or a cloud server and is used for exchanging the user key during each login.
In an embodiment, the key management service receives a client public key, such as a client _ pub _ key, sent by a client, and also generates a server private key and a server public key according to the client public key by using the first preset algorithm, such as through an ECDH algorithm, svr _ pub _ key and svr _ pri _ key, where svr _ pub _ key is the server public key and svr _ pri _ key is the server private key, and then the first sending unit 302 sends the server private key, that is, svr _ pri _ key, back to the client in a clear text.
The verifying unit 303 is configured to verify the validity of the server public key.
In an embodiment of the application, the verifying unit 303 may verify the validity of the public key of the server by using a preset pair of public and private keys. For example, a preset public key is set in the client, a preset private key is set in the key management service, then the key management service signs the server public key through the preset private key to generate a corresponding information digest while sending the server public key plaintext to the client, and then the key management service returns the information digest and the server public key plaintext to the client.
Further, after the client receives the loopback packet of the key management service, the verification unit 303 checks whether the signature of the information digest in the loopback packet is legal through a preset public key stored in the client, specifically, verifies whether the signature is issued by the corresponding key management service, because the preset public key is stored in the client and the preset private key is stored in the key management service, the preset private key is only known by a real background service, that is, the key management service, and if the verification is successful, it indicates that the validity of the server public key passes, that is, the received server public key is legal, and then the next operation can be executed.
And the encryption unit 304 is configured to generate a first symmetric key according to the server public key and the client private key when the verification unit passes the verification, and encrypt the third-party account data according to the first symmetric key based on a second preset algorithm.
In an embodiment, for example, when the client successfully verifies the signature through the preset verify _ key, it indicates that svr _ pub _ key obtained this time is legal, and a corresponding symmetric key may also be generated locally at the client, and specifically, a first symmetric key may be generated according to a public key of the server and a private key of the client, where the first symmetric key is, for example, share _ key ECDH _ general (svr _ pub _ key).
Further, after the client generates the first symmetric key, the encryption unit 304 may encrypt the third party account data according to the first symmetric key based on a second preset algorithm. The second predetermined algorithm may be a symmetric encryption algorithm, and in an embodiment, the third party account data may be encrypted by using an AES-GCM algorithm.
In the above whole interaction flow, before logging in each time, the client needs to exchange the public key of the server for one session with the key management service to uniquely generate the symmetric key of each session. Each exchange of each client generates a pair of unique public and private keys, and each calculated symmetric key is also session unique, so that the account login security of all users cannot be influenced due to key leakage.
In an embodiment, as shown in fig. 7, the encryption device for logging in by the third party account may further include:
a version obtaining unit 305, configured to obtain version information of the client by the key management service before the client performs third-party account login;
a second generating unit 306, configured to generate a preset public key and a preset private key according to the version information based on the third preset algorithm, where the key management service stores the preset private key and sends the preset public key to the client.
In an embodiment, the key management service signs the server public key through the preset private key and then returns the server public key to the client, and the verification unit 303 is specifically configured to verify the validity of the signature of the server public key through the preset public key.
In an embodiment, after the key management service generates a server-side private key and a server-side public key, the key management service generates a second symmetric key according to the server-side private key and a client-side public key. With continued reference to fig. 7, the encryption apparatus for third party account login may further include:
a second sending unit 307, configured to send the encrypted third party account data to a login service after the encryption unit 304 encrypts the third party account data according to the first symmetric key based on a second preset algorithm;
a key obtaining unit 308, configured to control the login service to obtain the second symmetric key from the key management service;
a decryption unit 309, configured to control the login service to decrypt the encrypted third party account data based on the second symmetric key, so as to generate the third party account data.
As can be seen from the above, in the embodiment of the present invention, when it is detected that third party account login is performed, the first generating unit 301 obtains third party account data, and generates a client private key and a client public key based on a first preset algorithm, the first sending unit 302 sends the client public key to the key management service, so that the key management service generates a server private key and a server public key according to the client public key based on the first preset algorithm, and returns the server public key to the client, the verifying unit 303 verifies the validity of the server public key, when it is determined that the validity verification of the server public key passes, the encrypting unit 304 generates a first symmetric key according to the server public key and the client private key, and encrypts the third party account data according to the first symmetric key based on a second preset algorithm. According to the embodiment of the application, the whole key negotiation process can be completed only by newly adding the network round-trip delay once, and the user key is isolated, so that the safety of service login data is effectively improved when a third-party account is logged in.
An embodiment of the present invention further provides a terminal, as shown in fig. 8, the terminal may include components such as a Radio Frequency (RF) circuit 601, a memory 602 including one or more computer-readable storage media, an input unit 603, a display unit 604, a sensor 605, an audio circuit 606, a Wireless Fidelity (WiFi) module 607, a processor 608 including one or more processing cores, and a power supply 609. Those skilled in the art will appreciate that the terminal structure shown in fig. 8 is not intended to be limiting and may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components. Wherein:
the RF circuit 601 may be used for receiving and transmitting signals during a message transmission or communication process, and in particular, for receiving downlink messages from a base station and then processing the received downlink messages by one or more processors 608; in addition, data relating to uplink is transmitted to the base station. In general, the RF circuit 601 includes, but is not limited to, an antenna, at least one Amplifier, a tuner, one or more oscillators, a Subscriber Identity Module (SIM) card, a transceiver, a coupler, a Low Noise Amplifier (LNA), a duplexer, and the like. In addition, the RF circuit 601 may also communicate with networks and other devices via wireless communications. The wireless communication may use any communication standard or protocol, including but not limited to Global System for Mobile communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, Short Messaging Service (SMS), and the like.
The memory 602 may be used to store software programs and modules, and the processor 608 executes various functional applications and information processing by operating the software programs and modules stored in the memory 602. The memory 602 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application program required by at least one function (such as a sound playing function, an image playing function, etc.), and the like; the storage data area may store data (such as audio data, a phonebook, etc.) created according to the use of the terminal, etc. Further, the memory 602 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device. Accordingly, the memory 602 may also include a memory controller to provide the processor 608 and the input unit 603 access to the memory 602.
The input unit 603 may be used to receive input numeric or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control. In particular, in one particular embodiment, input unit 603 may include a touch-sensitive surface as well as other input devices. The touch-sensitive surface, also referred to as a touch display screen or a touch pad, may collect touch operations by a user (e.g., operations by a user on or near the touch-sensitive surface using a finger, a stylus, or any other suitable object or attachment) thereon or nearby, and drive the corresponding connection device according to a predetermined program. Alternatively, the touch sensitive surface may comprise two parts, a touch detection means and a touch controller. The touch detection device detects the touch direction of a user, detects a signal brought by touch operation and transmits the signal to the touch controller; the touch controller receives touch information from the touch sensing device, converts the touch information into touch point coordinates, sends the touch point coordinates to the processor 608, and can receive and execute commands sent by the processor 608. In addition, touch sensitive surfaces may be implemented using various types of resistive, capacitive, infrared, and surface acoustic waves. The input unit 603 may include other input devices in addition to the touch-sensitive surface. In particular, other input devices may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, a joystick, and the like.
The display unit 604 may be used to display information input by or provided to the user and various graphical user interfaces of the terminal, which may be made up of graphics, text, icons, video, and any combination thereof. The Display unit 604 may include a Display panel, and optionally, the Display panel may be configured in the form of a Liquid Crystal Display (LCD), an Organic Light-Emitting Diode (OLED), or the like. Further, the touch-sensitive surface may overlay the display panel, and when a touch operation is detected on or near the touch-sensitive surface, the touch operation is transmitted to the processor 608 to determine the type of touch event, and the processor 608 then provides a corresponding visual output on the display panel according to the type of touch event. Although in FIG. 8 the touch sensitive surface and the display panel are two separate components to implement input and output functions, in some embodiments the touch sensitive surface may be integrated with the display panel to implement input and output functions.
The terminal may also include at least one sensor 605, such as a light sensor, motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor that may adjust the brightness of the display panel according to the brightness of ambient light, and a proximity sensor that may turn off the display panel and/or the backlight when the terminal is moved to the ear. As one of the motion sensors, the gravity acceleration sensor can detect the magnitude of acceleration in each direction (generally, three axes), can detect the magnitude and direction of gravity when the mobile phone is stationary, and can be used for applications of recognizing the posture of the mobile phone (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer and tapping), and the like; as for other sensors such as a gyroscope, a barometer, a hygrometer, a thermometer, and an infrared sensor, which can be configured in the terminal, detailed description is omitted here.
Audio circuitry 606, a speaker, and a microphone may provide an audio interface between the user and the terminal. The audio circuit 606 may transmit the electrical signal converted from the received audio data to a speaker, and convert the electrical signal into a sound signal for output; on the other hand, the microphone converts the collected sound signal into an electric signal, which is received by the audio circuit 606 and converted into audio data, which is then processed by the audio data output processor 608, and then transmitted to, for example, another terminal via the RF circuit 601, or the audio data is output to the memory 602 for further processing. The audio circuit 606 may also include an earbud jack to provide communication of peripheral headphones with the terminal.
WiFi belongs to short-distance wireless transmission technology, and the terminal can help a user to receive and send e-mails, browse webpages, access streaming media and the like through the WiFi module 607, and provides wireless broadband internet access for the user. Although fig. 8 shows the WiFi module 607, it is understood that it does not belong to the essential constitution of the terminal, and may be omitted entirely as needed within the scope not changing the essence of the invention.
The processor 608 is a control center of the terminal, connects various parts of the entire handset using various interfaces and lines, and performs various functions of the terminal and processes data by operating or executing software programs and/or modules stored in the memory 602 and calling data stored in the memory 602, thereby performing overall monitoring of the handset. Optionally, processor 608 may include one or more processing cores; preferably, the processor 608 may integrate an application processor, which primarily handles operating systems, user interfaces, applications, etc., and a modem processor, which primarily handles wireless communications. It will be appreciated that the modem processor described above may not be integrated into the processor 608.
The terminal also includes a power supply 609 (e.g., a battery) for powering the various components, which may preferably be logically connected to the processor 608 via a power management system that may be used to manage charging, discharging, and power consumption. The power supply 609 may also include any component of one or more dc or ac power sources, recharging systems, power failure detection circuitry, power converters or inverters, power status indicators, and the like.
Although not shown, the terminal may further include a camera, a bluetooth module, and the like, which will not be described herein. Specifically, in this embodiment, the processor 608 in the terminal loads the executable file corresponding to the process of one or more application programs into the memory 602 according to the following instructions, and the processor 608 runs the application programs stored in the memory 602, thereby implementing various functions:
when the third-party account login is detected, third-party account data are obtained, a client-side private key and a client-side public key are generated based on a first preset algorithm, the client-side public key is sent to a key management service, the key management service generates a server-side private key and a server-side public key according to the client-side public key based on the first preset algorithm, the server-side public key is returned to the client side, the legality of the server-side public key is verified, when the legality verification of the server-side public key is confirmed to be passed, a first symmetric key is generated according to the server-side public key and the client-side private key, and the third-party account data are encrypted according to the first symmetric key based on a.
In the above embodiments, the descriptions of the embodiments have respective emphasis, and a part which is not described in detail in a certain embodiment may refer to the above detailed description of the encryption method for third party account login, and is not described herein again.
As can be seen from the above, the terminal according to the embodiment of the present invention may obtain third party account data when detecting that third party account login is performed, generate a client private key and a client public key based on a first preset algorithm, and send the client public key to the key management service, so that the key management service generates a server private key and a server public key according to the client public key based on the first preset algorithm, returns the server public key to the client, verifies the validity of the server public key, generates a first symmetric key according to the server public key and the client private key when it is determined that the validity verification of the server public key passes, and encrypts the third party account data according to the first symmetric key based on a second preset algorithm. According to the embodiment of the application, the whole key negotiation process can be completed only by newly adding the network round-trip delay once, and the user key is isolated, so that the safety of service login data is effectively improved when a third-party account is logged in.
It will be understood by those skilled in the art that all or part of the steps of the methods of the above embodiments may be performed by instructions or by associated hardware controlled by the instructions, which may be stored in a computer readable storage medium and loaded and executed by a processor.
To this end, an embodiment of the present invention provides a storage medium, where a plurality of instructions are stored, where the instructions can be loaded by a processor to perform steps in any one of the encryption methods for third party account login provided in the embodiments of the present invention. For example, the instructions may perform the steps of:
when the third-party account login is detected, third-party account data are obtained, a client-side private key and a client-side public key are generated based on a first preset algorithm, the client-side public key is sent to a key management service, the key management service generates a server-side private key and a server-side public key according to the client-side public key based on the first preset algorithm, the server-side public key is returned to the client side, the legality of the server-side public key is verified, when the legality verification of the server-side public key is confirmed to be passed, a first symmetric key is generated according to the server-side public key and the client-side private key, and the third-party account data are encrypted according to the first symmetric key based on a.
The above operations can be implemented in the foregoing embodiments, and are not described in detail herein.
Wherein the storage medium may include: read Only Memory (ROM), Random Access Memory (RAM), magnetic or optical disks, and the like.
Since the instructions stored in the storage medium may execute the steps in any one of the encryption methods for third party account login provided by the embodiments of the present invention, beneficial effects that can be achieved by any one of the encryption methods for third party account login provided by the embodiments of the present invention may be achieved, which are detailed in the foregoing embodiments and will not be described herein again.
The encryption method, device, storage medium and terminal for third party account login provided by the embodiment of the present invention are described in detail above, a specific example is applied in the present document to explain the principle and the implementation of the present invention, and the description of the above embodiment is only used to help understanding the method and the core idea of the present invention; meanwhile, for those skilled in the art, according to the idea of the present invention, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present invention.

Claims (10)

1. An encryption method for third party account login is characterized by comprising the following steps:
when the third party account login is detected, acquiring the third party account data, and generating a client private key and a client public key based on a first preset algorithm;
sending the client public key to a key management service so that the key management service generates a server private key and a server public key according to the client public key based on the first preset algorithm, and returns the server public key to the client;
verifying the validity of the server public key;
and when the validity verification of the server public key is confirmed to pass, generating a first symmetric key according to the server public key and a client private key, and encrypting the third party account data according to the first symmetric key based on a second preset algorithm.
2. The encryption method for third party account login according to claim 1, wherein before the client performs third party account login, the method further comprises:
the key management service acquires version information of the client;
generating a preset public key and a preset private key according to the version information based on the third preset algorithm;
and the key management service stores the preset private key and sends the preset public key to the client.
3. The encryption method for third party account login according to claim 2, wherein the step of returning the server public key to the client comprises:
the server public key is signed by the preset private key and then returned to the client;
the step of verifying the validity of the server public key comprises the following steps:
and verifying the validity of the signature of the server public key through the preset public key.
4. The encryption method for third party account login according to claim 1, wherein after the key management service generates the server private key and the server public key, the method further comprises:
and the key management service generates a second symmetric key according to the server-side private key and the client-side public key.
5. The encryption method for third party account login according to claim 4, wherein after the third party account data is encrypted according to the first symmetric key based on the second preset algorithm, the method further comprises:
sending the encrypted third party account data to a login service;
the login service acquires the second symmetric key from the key management service;
and the login service decrypts the encrypted third party account data based on the second symmetric key to generate the third party account data.
6. The encryption method for third party account login according to claim 5, wherein after the login service generates the third party account data, the method further comprises:
the login service sends the third party account data to a third party authentication server;
the third party authentication server verifies the legality of the user identity according to the third party account data;
and if the user identity is confirmed to be legal, the third-party server acquires the associated information of the user and sends the associated information to the login service so that the login service returns the associated information to the client.
7. The encryption method for third party account login according to claim 5, wherein the encrypted third party account data carries device information, and the step of the login service acquiring the second symmetric key from the key management service includes:
and the login service acquires the second symmetric key from the key management service according to the equipment information.
8. The encryption method for third party account login according to claim 1, wherein the processing method according to claim 1 is further comprising, before the client performs third party account login:
the key management service generates a spare public key and a spare private key, stores the spare private key and sends the spare public key to the client;
after the insufficiency of verifying the validity of the server-side public key, the method further includes:
and when the validity verification of the server public key is not passed, generating a third symmetric key according to the standby public key and a client private key, and encrypting the third party account data according to the third symmetric key based on a second preset algorithm.
9. An encryption device for logging in a third party account is characterized by comprising:
the first generation unit is used for acquiring third party account data when the third party account login is detected, and generating a client private key and a client public key based on a first preset algorithm;
the first sending unit is used for sending the client public key to a key management service so that the key management service generates a server private key and a server public key according to the client public key based on the first preset algorithm and returns the server public key to the client;
the verifying unit is used for verifying the validity of the server public key;
and the encryption unit is used for generating a first symmetric key according to the server public key and the client private key when the verification unit passes the verification, and encrypting the third party account data according to the first symmetric key based on a second preset algorithm.
10. A storage medium storing instructions adapted to be loaded by a processor to perform the steps of the encryption method for third party account login according to any one of claims 1 to 8.
CN201910683098.8A 2019-07-26 2019-07-26 Encryption method and device for third party account login and storage medium Active CN111193695B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910683098.8A CN111193695B (en) 2019-07-26 2019-07-26 Encryption method and device for third party account login and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910683098.8A CN111193695B (en) 2019-07-26 2019-07-26 Encryption method and device for third party account login and storage medium

Publications (2)

Publication Number Publication Date
CN111193695A true CN111193695A (en) 2020-05-22
CN111193695B CN111193695B (en) 2021-07-06

Family

ID=70709038

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910683098.8A Active CN111193695B (en) 2019-07-26 2019-07-26 Encryption method and device for third party account login and storage medium

Country Status (1)

Country Link
CN (1) CN111193695B (en)

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112073185A (en) * 2020-08-11 2020-12-11 广州点云科技有限公司 Cloud game secure transmission method and device
CN112187832A (en) * 2020-11-03 2021-01-05 北京指掌易科技有限公司 Data transmission method and electronic equipment
CN112202792A (en) * 2020-09-30 2021-01-08 京东数字科技控股股份有限公司 Communication method and device for establishing long connection between client and server
CN112966286A (en) * 2021-03-30 2021-06-15 建信金融科技有限责任公司 Method, system, device and computer readable medium for user login
CN113641985A (en) * 2021-10-12 2021-11-12 江苏荣泽信息科技股份有限公司 Distributed trusted organization identity access control system and method
CN114500055A (en) * 2022-01-27 2022-05-13 建信金融科技有限责任公司 Password verification method and device, electronic equipment and storage medium
CN114531235A (en) * 2022-03-01 2022-05-24 中国科学院软件研究所 End-to-end encrypted communication method and system
CN114615012A (en) * 2022-01-28 2022-06-10 北京威尔文教科技有限责任公司 Device connection method and device, electronic device and readable storage medium
CN115001865A (en) * 2022-07-28 2022-09-02 杭州安司源科技有限公司 Communication processing method and system, client, communication server and supervision server
CN115037451A (en) * 2021-11-19 2022-09-09 荣耀终端有限公司 Data protection method and electronic equipment
WO2022206349A1 (en) * 2021-04-02 2022-10-06 腾讯科技（深圳）有限公司 Information verification method, related apparatus, device, and storage medium
WO2022252356A1 (en) * 2021-06-03 2022-12-08 腾讯云计算（北京）有限责任公司 Data processing method and apparatus, electronic device, and medium
CN115499122A (en) * 2022-11-15 2022-12-20 平安银行股份有限公司 External partner access method, electronic device, and computer storage medium
EP4340333A4 (en) * 2021-08-04 2024-05-01 Boe Technology Group Co Ltd Communication protocol conversion method, and device, system, and gateway device

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102739708A (en) * 2011-04-07 2012-10-17 腾讯科技（深圳）有限公司 System and method for accessing third party application based on cloud platform
CN103095704A (en) * 2013-01-15 2013-05-08 杭州华三通信技术有限公司 Trusted medium online validation method and device
CN104184701A (en) * 2013-05-21 2014-12-03 腾讯科技（深圳）有限公司 Third-party application log-in method, device and terminal
CN104836776A (en) * 2014-02-10 2015-08-12 阿里巴巴集团控股有限公司 Data interaction method and device
CN105187431A (en) * 2015-09-17 2015-12-23 网易（杭州）网络有限公司 Log-in method, server, client and communication system for third party application
CN105871866A (en) * 2016-04-28 2016-08-17 济南大学 System and method for password management based on computer hardware information
US20170034133A1 (en) * 2015-07-28 2017-02-02 International Business Machines Corporation User authentication over networks
US20180076956A1 (en) * 2016-02-02 2018-03-15 International Business Machines Corporation System and method for generating a server-assisted strong password from a weak secret
CN108347419A (en) * 2017-01-24 2018-07-31 腾讯科技（深圳）有限公司 Data transmission method and device
CN108471404A (en) * 2018-02-28 2018-08-31 深圳市达仁基因科技有限公司 File sharing method, device, computer equipment and storage medium
CN108965331A (en) * 2018-08-29 2018-12-07 腾讯科技（深圳）有限公司 Log in method of calibration, device and login system

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102739708A (en) * 2011-04-07 2012-10-17 腾讯科技（深圳）有限公司 System and method for accessing third party application based on cloud platform
CN103095704A (en) * 2013-01-15 2013-05-08 杭州华三通信技术有限公司 Trusted medium online validation method and device
CN104184701A (en) * 2013-05-21 2014-12-03 腾讯科技（深圳）有限公司 Third-party application log-in method, device and terminal
CN104836776A (en) * 2014-02-10 2015-08-12 阿里巴巴集团控股有限公司 Data interaction method and device
US20170034133A1 (en) * 2015-07-28 2017-02-02 International Business Machines Corporation User authentication over networks
CN105187431A (en) * 2015-09-17 2015-12-23 网易（杭州）网络有限公司 Log-in method, server, client and communication system for third party application
US20180076956A1 (en) * 2016-02-02 2018-03-15 International Business Machines Corporation System and method for generating a server-assisted strong password from a weak secret
CN105871866A (en) * 2016-04-28 2016-08-17 济南大学 System and method for password management based on computer hardware information
CN108347419A (en) * 2017-01-24 2018-07-31 腾讯科技（深圳）有限公司 Data transmission method and device
CN108471404A (en) * 2018-02-28 2018-08-31 深圳市达仁基因科技有限公司 File sharing method, device, computer equipment and storage medium
CN108965331A (en) * 2018-08-29 2018-12-07 腾讯科技（深圳）有限公司 Log in method of calibration, device and login system

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112073185A (en) * 2020-08-11 2020-12-11 广州点云科技有限公司 Cloud game secure transmission method and device
CN112202792A (en) * 2020-09-30 2021-01-08 京东数字科技控股股份有限公司 Communication method and device for establishing long connection between client and server
CN112187832A (en) * 2020-11-03 2021-01-05 北京指掌易科技有限公司 Data transmission method and electronic equipment
CN112966286A (en) * 2021-03-30 2021-06-15 建信金融科技有限责任公司 Method, system, device and computer readable medium for user login
CN112966286B (en) * 2021-03-30 2023-01-24 中国建设银行股份有限公司 Method, system, device and computer readable medium for user login
WO2022206349A1 (en) * 2021-04-02 2022-10-06 腾讯科技（深圳）有限公司 Information verification method, related apparatus, device, and storage medium
WO2022252356A1 (en) * 2021-06-03 2022-12-08 腾讯云计算（北京）有限责任公司 Data processing method and apparatus, electronic device, and medium
EP4340333A4 (en) * 2021-08-04 2024-05-01 Boe Technology Group Co Ltd Communication protocol conversion method, and device, system, and gateway device
CN113641985A (en) * 2021-10-12 2021-11-12 江苏荣泽信息科技股份有限公司 Distributed trusted organization identity access control system and method
CN115037451B (en) * 2021-11-19 2023-04-14 荣耀终端有限公司 Data protection method and electronic equipment
CN115037451A (en) * 2021-11-19 2022-09-09 荣耀终端有限公司 Data protection method and electronic equipment
CN114500055B (en) * 2022-01-27 2023-06-27 建信金融科技有限责任公司 Password verification method and device, electronic equipment and storage medium
CN114500055A (en) * 2022-01-27 2022-05-13 建信金融科技有限责任公司 Password verification method and device, electronic equipment and storage medium
CN114615012A (en) * 2022-01-28 2022-06-10 北京威尔文教科技有限责任公司 Device connection method and device, electronic device and readable storage medium
CN114531235A (en) * 2022-03-01 2022-05-24 中国科学院软件研究所 End-to-end encrypted communication method and system
CN114531235B (en) * 2022-03-01 2023-06-13 中国科学院软件研究所 Communication method and system for end-to-end encryption
CN115001865B (en) * 2022-07-28 2022-12-02 杭州安司源科技有限公司 Communication processing method and system, client, communication server and supervision server
CN115001865A (en) * 2022-07-28 2022-09-02 杭州安司源科技有限公司 Communication processing method and system, client, communication server and supervision server
WO2024021958A1 (en) * 2022-07-28 2024-02-01 杭州安司源科技有限公司 Communication processing method and system, client, communication server and supervision server
CN115499122A (en) * 2022-11-15 2022-12-20 平安银行股份有限公司 External partner access method, electronic device, and computer storage medium
CN115499122B (en) * 2022-11-15 2023-04-28 平安银行股份有限公司 External partner access method, electronic device, and computer storage medium

Also Published As

Publication number Publication date
CN111193695B (en) 2021-07-06

Similar Documents

Publication Publication Date Title
CN111193695B (en) Encryption method and device for third party account login and storage medium
CN112733107B (en) Information verification method, related device, equipment and storage medium
CN109600223B (en) Verification method, activation method, device, equipment and storage medium
US11088836B2 (en) Key updating method, apparatus, and system
US11456864B2 (en) Information storage method, device, and computer-readable storage medium
EP3605989B1 (en) Information sending method, information receiving method, apparatus, and system
WO2018014723A1 (en) Key management method, apparatus, device and system
US20190236300A1 (en) Service processing method and apparatus, data sharing system, and storage medium
WO2019120091A1 (en) Identity authentication method and system, and computing device
CN110417543B (en) Data encryption method, device and storage medium
WO2017041599A1 (en) Service processing method and electronic device
CN111737366B (en) Private data processing method, device, equipment and storage medium of block chain
CN110198301B (en) Service data acquisition method, device and equipment
CN104954126B (en) Sensitive operation verification method, device and system
US10601590B1 (en) Secure secrets in hardware security module for use by protected function in trusted execution environment
CN109768977B (en) Streaming media data processing method and device, related equipment and medium
US10454905B2 (en) Method and apparatus for encrypting and decrypting picture, and device
CN107154935B (en) Service request method and device
EP3439266B1 (en) Processing resource requests on a mobile device
WO2018108123A1 (en) Identity authentication method, device and system
WO2018108062A1 (en) Method and device for identity verification, and storage medium
CN113037741A (en) Authentication method and related device
CN109086595B (en) Service account switching method, system, device and server
CN113821821A (en) Security architecture system, cryptographic operation method of security architecture system and computing device
WO2023226778A1 (en) Identity authentication method and apparatus, and electronic device and computer-readable storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant