CN112671538B

CN112671538B - Key updating method, device, system, storage medium and computing equipment

Info

Publication number: CN112671538B
Application number: CN202110278634.3A
Authority: CN
Inventors: 徐贵洲
Original assignee: Beijing Acoinfo Technology Co ltd
Current assignee: Beijing Acoinfo Technology Co ltd
Priority date: 2021-03-16
Filing date: 2021-03-16
Publication date: 2021-06-22
Anticipated expiration: 2041-03-16
Also published as: CN112671538A

Abstract

The application discloses a method, a device, a system, a storage medium and a computing device for updating a secret key, wherein the method comprises the following steps: initiating an access request to a target server by using a first token issued by an issuing organization, wherein the first token is encrypted by using a first private key corresponding to a first public key; receiving a response of the target server for verifying the first token by using the local public key, wherein the response is packaged with an identifier of the local public key; analyzing the response, and when the response indicates that the verification is invalid, acquiring a second token issued by an issuing organization, wherein the second token is encrypted by using a second private key corresponding to the local public key, and the first public key is packaged in the second token; and initiating an access request to the target server by using the second token so that the target server verifies that the second token is valid by using the local public key, and updating the local public key into the first public key packaged in the second token so as to enable the target server to be accessed by the first token. The method and the device solve the technical problem that the key is not updated timely in the prior art.

Description

Key updating method, device, system, storage medium and computing equipment

Technical Field

The present application relates to the field of information security technologies, and in particular, to a method, an apparatus, a system, a storage medium, and a computing device for updating a key.

Background

User authentication techniques generally employ Cookies + sessions for authentication. When a user requests a server for the first time, the server creates a corresponding Session according to related information submitted by the user, and returns the Session unique identification information Session ID of the Session to the browser when the request is returned; after receiving the sessionID information returned by the server, the browser stores the information into the Cookie, and the Cookie records which domain name the sessionID belongs to; when a user accesses the server for the second time, the request can automatically judge whether Cookie information exists under the domain name, if the Cookie information exists, the Cookie information is automatically sent to the server, the server can obtain the Session ID from the Cookie, then the corresponding Session information is searched according to the Session ID, if the Session ID is not found, the user does not log in or fails to log in, and if the Session is found, the user can execute the following operation after logging in.

The popularization of distributed web application is that the cost for managing the user login state through session is higher and higher, and the method slowly develops into a method of using a token (token) to check the login identity. I.e. the client requests to log on to the server using a username and password. The server receives the request to verify the user name and the password; after successful verification, the server will issue a token and send the token to the client. The client stores the token after receiving the token, the token issued by the server needs to be taken by the client when the client requests resources from the server every time, the server receives the request, then verifies the token taken by the client request, and if the verification is successful, the requested data is returned to the client.

JWT, known as Json Web Token, is a JSON-based open standard ((RFC 7519) that is implemented for the transfer of assertions between network application environments.A compact, self-contained method is defined for securely transferring information in the form of JSON objects between two communicating parties.

In an asymmetric scenario, the client C program connects to the server program S using an asymmetric encrypted JWT Token. The Token is issued by using a private key, and the server program verifies the signature in the Token by using a public key which is obtained in advance and matched with the issued private key, so that the validity of the Token is confirmed. FIG. 1 shows a prior art JWT-based authentication process, which includes:

1. a user logs in a server program S at a client C by using an account and a password;

2. the server S uses the private key to create a JWT after passing the verification;

3. the server S returns the JWT to the client C, and the client C stores the JWT;

4. the client C sends the JWT string in a request header like the server S;

5. the server S verifies the JWT:

a. the server returns the response data to the client browser after the verification is passed, and the client browser displays the data;

b. and if the verification fails, the server returns error information to the client browser, and the client browser displays an error prompt.

In an asymmetric encryption scenario, the token is generally issued by the program a of the third-party issuing authority, and the target server S only needs to obtain, through a trusted approach (such as HTTPS connection), a public key corresponding to a private key used when the program a of the third-party issuing authority is signed. The target server S can complete token verification only by using the public key. However, when the target server S goes offline, the connection with the program a of the third party token issuing authority is disconnected, and the issued tokens all use the updated private key just after the program a of the issuing authority updates the key pair, and the public key in the target server S is not updated offline, so that the newly issued token cannot complete the verification using the expired public key held by the target server S.

Aiming at the technical problem that the key is not updated timely in the prior art, an effective solution is not provided at present.

Disclosure of Invention

The embodiment of the application provides a method, a device, a system, a storage medium and a computing device for updating a secret key, so as to at least solve the technical problem that the secret key is not updated timely in the prior art.

According to an aspect of an embodiment of the present application, there is provided a key updating method applied to a mobile terminal, the method including: initiating an access request to a target server by using a first token issued by an issuing organization, wherein the first token is encrypted by using a first private key corresponding to a first public key; receiving a response that the target server verifies the first token using the local public key, wherein the target server is configured to package an identification of the local public key in the response when the token verification is invalid; analyzing the response, and when the response indicates that the verification is invalid, acquiring a second token issued by the issuing organization, wherein the second token is encrypted by using a second private key corresponding to the local public key, and the first public key is packaged in the second token; and initiating an access request to the target server by using the second token so that the target server verifies that the second token is valid by using the local public key, and updating the local public key into the first public key packaged in the second token so as to enable the target server to be accessed by the first token.

According to an aspect of the embodiments of the present application, there is also provided a key updating method applied to a target server, the method including: receiving an access request initiated by the mobile terminal by using a first token, wherein the first token is issued by an issuing organization and is encrypted by using a first private key corresponding to a first public key; verifying whether the first token is valid using the local public key; if the verification is invalid, sending a response of the identifier packaged with the local public key to the mobile terminal so that the mobile terminal can acquire a second token issued by an issuing organization, wherein the second token is encrypted by using a second private key corresponding to the local public key, and the first public key is packaged in the second token; receiving an access request initiated by the mobile terminal by using the second token; and verifying that the second token is valid by using the local public key, and updating the local public key into the first public key packaged in the second token so as to enable the target server to be accessed through the first token.

According to an aspect of the embodiments of the present application, there is also provided a key updating method applied to an issuing authority, the method including: updating the key pair, and encrypting the first token by using the updated first private key corresponding to the first public key; issuing a first token to the mobile terminal, so that the mobile terminal initiates an access request to a target server by using the first token, wherein the target server is configured to verify the first token by using a local public key, and package an identifier of the local public key in a response and return the identifier to the mobile terminal when the verification is invalid; receiving a second token issuing request sent by the mobile terminal, wherein the second token issuing request comprises an identifier of a local public key; packaging the first public key in a second token, and encrypting the second token by using a second private key corresponding to the local public key; and issuing a second token to the mobile terminal, so that the mobile terminal initiates an access request to the target server by using the second token, so that the target server verifies that the second token is valid by using the local public key, and updates the local public key into a first public key packaged in the second token, thereby enabling the target server to be accessed by the first token.

According to an aspect of the embodiments of the present application, there is also provided a key updating method applied to an issuing authority, the method including: updating the key pair to obtain a new private key and a new public key; generating a verification first token, wherein the verification first token is encrypted with the new private key; generating an updated second token, wherein the updated second token is encrypted with an old private key and wherein the new public key is packaged; issuing the verification first token and the update second token to the mobile terminal, wherein the mobile terminal is configured to: and initiating an access request to a target server by using the first token, receiving a response of the target server for verifying the first token by using a local public key, and initiating an access request to the target server by using the second token when the response indicates that the verification is invalid because the local public key of the target server is an old public key, so that the target server verifies that the second token is valid by using the old public key, and updates the local public key to a new public key packaged in the second token.

According to an aspect of the embodiment of the present application, there is also provided a key updating apparatus applied to a mobile terminal, including a first requesting unit, configured to initiate an access request to a target server using a first token issued by an issuing authority, where the first token is encrypted using a first private key corresponding to a first public key; a receiving unit, configured to receive a response that the target server verifies the first token using the local public key, where the target server is configured to package an identification of the local public key in the response when the token verification is invalid; the analysis unit is used for analyzing the response, and acquiring a second token issued by the issuing organization when the response indicates that the verification is invalid, wherein the second token is encrypted by using a second private key corresponding to the local public key, and the first public key is packaged in the second token; and the second request unit is used for initiating an access request to the target server by using the second token so that the target server verifies that the second token is valid by using the local public key, and updating the local public key into the first public key packaged in the second token so as to enable the target server to be accessed by the first token.

According to an aspect of the embodiment of the present application, there is also provided a key updating apparatus, applied to a target server, including a first request receiving unit, configured to receive an access request initiated by a mobile terminal using a first token, where the first token is issued by an issuing authority, and the first token is encrypted using a first private key corresponding to a first public key; a first verifying unit for verifying whether the first token is valid using the local public key; the response unit is used for sending a response packaged with the identification of the local public key to the mobile terminal if the verification is invalid, so that the mobile terminal can obtain a second token issued by an issuing organization, wherein the second token is encrypted by using a second private key corresponding to the local public key, and the first public key is packaged in the second token; a second request receiving unit, configured to receive an access request initiated by the mobile terminal using the second token; and the second verification unit is used for verifying that the second token is valid by using the local public key and updating the local public key into the first public key packaged in the second token so as to enable the target server to be accessed through the first token.

According to an aspect of the embodiment of the present application, there is also provided a key updating apparatus applied to an issuing authority, including an updating unit, configured to update a key pair, and encrypt a first token using an updated first private key corresponding to a first public key; the system comprises a first token issuing unit, a target server and a second token issuing unit, wherein the first token issuing unit is used for issuing a first token to the mobile terminal so that the mobile terminal initiates an access request to the target server by using the first token, the target server is configured to verify the first token by using a local public key, and when the verification is invalid, the identifier of the local public key is packaged in a response and returned to the mobile terminal; the token request unit is used for receiving a second token issuing request sent by the mobile terminal, wherein the second token issuing request comprises an identifier of a local public key; the token generation unit is used for packaging the first public key in the second token and encrypting the second token by using a second private key corresponding to the local public key; and the second token issuing unit is used for issuing a second token to the mobile terminal, so that the mobile terminal initiates an access request to the target server by using the second token, the target server verifies that the second token is valid by using the local public key, and the local public key is updated to the first public key packaged in the second token, so that the target server can be accessed by the first token.

According to an aspect of the embodiments of the present application, there is also provided a key updating apparatus applied to an issuing authority, including: the updating unit is used for updating the key pair to obtain a new private key and a new public key; the first token generation unit is used for generating a first token, wherein the first token is encrypted by a new private key; a second token generation unit for generating a second token, wherein the second token is encrypted with an old private key and is wrapped with a new public key; a token issuing unit for issuing a first token and a second token to the mobile terminal, wherein the mobile terminal is configured to: and initiating an access request to a target server by using the first token, receiving a response of the target server for verifying the first token by using a local public key, and initiating an access request to the target server by using the second token when the response indicates that the verification is invalid because the local public key of the target server is an old public key, so that the target server verifies that the second token is valid by using the old public key, and updates the local public key to a new public key packaged in the second token.

According to an aspect of the embodiments of the present application, there is also provided a key update system, including an issuing authority, a mobile terminal, and a target server, wherein: the issuing authority updates the key pair and issues a first token to the mobile terminal, wherein the first token is encrypted by using a first private key corresponding to the first public key after updating; the mobile terminal initiates an access request to a target server by using a first token; the target server verifies whether the first token is valid by using the local public key; if the verification is invalid, sending a response of the identifier packaged with the local public key to the mobile terminal; the mobile terminal analyzes the response, and when the response indicates that the verification is invalid, the mobile terminal requests an issuing organization to issue a second token according to the identification of the local public key; the issuing organization issues a second token to the mobile terminal, wherein the second token is packaged with a first public key and is encrypted by using a second private key corresponding to the local public key; the mobile terminal initiates an access request to the target server by using the second token; the target server uses the local public key to verify that the second token is valid, and updates the local public key to the first public key packaged in the second token, so that the target server can be accessed through the first token.

On the basis of any of the above embodiments, obtaining the second token issued by the issuing authority when the response indicates that the verification is invalid comprises: initiating a second token issuing request to an issuing organization, wherein the second token issuing request comprises an identification of a local public key, receiving a second token returned by the issuing organization, and the issuing organization is configured to pack the first public key in the second token and encrypt the second token by using a second private key corresponding to the local public key; or according to the identification of the local public key, determining a second private key corresponding to the local public key, and searching a second token encrypted by using the second private key from a plurality of tokens locally stored in the mobile terminal, wherein the first public key is packaged in the second token.

On the basis of any of the above embodiments, after updating the local public key to the first public key packaged in the second token, the method further includes: initiating an access request to a target server by using a first token issued by an issuing organization; the target server verifies that the first token is valid by using the updated local public key; the target server returns the resource indicated by the access request.

On the basis of any of the above embodiments, before initiating the access request to the target server using the first token issued by the issuing authority, the method further includes: monitoring whether a target server is online; and when the target server is monitored to be offline, triggering the mobile terminal to establish local area network connection with the target server so as to initiate an access request to the target server through the mobile terminal.

On the basis of any of the above embodiments, after the mobile terminal establishes a local area network connection with the target server, the method further includes: the mobile terminal establishes connection with an issuing mechanism; the mobile terminal verifies the validity of the issuing mechanism; after the mobile terminal verifies that the issuing mechanism is valid, the mobile terminal logs in the issuing mechanism through a pre-stored user name and password so as to trigger the issuing mechanism to issue a token.

On the basis of any of the above embodiments, the first token and the second token are asymmetric JWT tokens.

On the basis of any of the above embodiments, the target server verifying the first token using the local public key includes: reading a public key required for verification from a header of the first token; judging whether the local public key is consistent with the read public key required by verification; if yes, the target server verifies that the first token is valid; if not, the target server verifies that the first token is invalid.

On the basis of any of the above embodiments, packaging the first public key in the second token includes: the first public key is written into the payload of the second token.

According to another aspect of the embodiments of the present application, there is provided a storage medium including a stored program, wherein when the program runs, a device on which the storage medium is located is controlled to execute the method of any of the above embodiments.

According to another aspect of embodiments of the present application, there is provided a computing device comprising a processor for executing a program, wherein the program executes to perform the method of any of the above embodiments.

In the embodiment of the application, in the case that the target server cannot be connected with the network and is offline, or in the case that the target server cannot be connected with the issuing organization, the mobile terminal in the same local area network with the target server establishes connection with the target server, or the mobile terminal establishes connection with the target server through a near field communication technology. Meanwhile, the issuing authority updates the key pair regularly, and a local public key used by the target server is possibly inconsistent with the updated key pair due to the fact that the target server is offline, and based on the fact, the mobile terminal initiates an access request to the target server by using a first token issued by the issuing authority, wherein the first token is encrypted by using a first private key corresponding to the first public key; the target server verifies whether the first token is valid by using the local public key; if the verification is invalid, sending a response of the identifier packaged with the local public key to the mobile terminal; the mobile terminal analyzes the response, and when the response indicates that the verification is invalid, the mobile terminal requests an issuing organization to issue a second token according to the identification of the local public key; the issuing organization issues a second token to the mobile terminal, wherein the second token is packaged with a first public key and is encrypted by using a second private key corresponding to the local public key; the mobile terminal initiates an access request to the target server by using the second token; the target server uses the local public key to verify that the second token is valid, and updates the local public key to the first public key packaged in the second token, so that the target server can be accessed through the first token. The method and the system realize that the local public key in the target server is updated by connecting the issuing organization through the mobile terminal and using the mobile terminal as a transfer organization under the condition that the target server is offline and the key pair of the issuing organization is updated, thereby solving the technical problem that the key is not updated timely in the prior art.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:

FIG. 1 is a prior art JWT based authentication flow diagram;

fig. 2 is a block diagram of a hardware structure of a computer terminal (or mobile device) for implementing a key update method according to an embodiment of the present application;

FIG. 3 is a flow chart of a method of rekeying according to an embodiment of the present application;

FIG. 4 is a flow chart of JWT based authentication according to an embodiment of the present application;

FIG. 5 is a flow chart of yet another rekeying method according to an embodiment of the present application;

6a-b are flow diagrams of yet another method of rekeying according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of a key update apparatus according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of another key update apparatus according to an embodiment of the present application; and

fig. 9a-b are schematic structural diagrams of still another key update apparatus according to an embodiment of the present application.

Detailed Description

In order to make the technical solutions better understood by those skilled in the art, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only partial embodiments of the present application, but not all 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 application.

It should be noted that the terms "first," "second," and the like in the description and claims of this application and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the application described herein are capable of operation in sequences other than those illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

Example 1

There is also provided, in accordance with an embodiment of the present application, a key update method embodiment, it should be noted that the steps illustrated in the flowchart of the accompanying drawings may be performed in a computer system such as a set of computer executable instructions, and that, although a logical order is illustrated in the flowchart, in some cases, the steps illustrated or described may be performed in an order different than that described herein.

The method provided by the first embodiment of the present application may be executed in a mobile terminal, a computer terminal, or a similar computing device. Fig. 2 shows a hardware configuration block diagram of a computer terminal (or mobile device) for implementing the key update method. As shown in fig. 2, the computer terminal 10 (or mobile device 10) may include one or more (shown as 102a, 102b, … …, 102 n) processors 102 (the processors 102 may include, but are not limited to, a processing device such as a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. Besides, the method can also comprise the following steps: a display, an input/output interface (I/O interface), a Universal Serial Bus (USB) port (which may be included as one of the ports of the I/O interface), a network interface, a power source, and/or a camera. It will be understood by those skilled in the art that the structure shown in fig. 2 is only an illustration and is not intended to limit the structure of the electronic device. For example, the computer terminal 10 may also include more or fewer components than shown in FIG. 2, or have a different configuration than shown in FIG. 2.

It should be noted that the one or more processors 102 and/or other data processing circuitry described above may be referred to generally herein as "data processing circuitry". The data processing circuitry may be embodied in whole or in part in software, hardware, firmware, or any combination thereof. Further, the data processing circuit may be a single stand-alone processing module, or incorporated in whole or in part into any of the other elements in the computer terminal 10 (or mobile device). As referred to in the embodiments of the application, the data processing circuit acts as a processor control (e.g. selection of a variable resistance termination path connected to the interface).

The memory 104 may be used to store software programs and modules of application software, such as program instructions/data storage devices corresponding to the key update method in the embodiment of the present application, and the processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, so as to implement the above-mentioned key update method. The memory 104 may include high speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include memory located remotely from the processor 102, which may be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The transmission device 106 is used for receiving or transmitting data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network adapter (NIC) that can be connected to other Network devices through a base station to communicate with the internet. In one example, the transmission device 106 can be a Radio Frequency (RF) module, which is used to communicate with the internet in a wireless manner.

The display may be, for example, a touch screen type Liquid Crystal Display (LCD) that may enable a user to interact with a user interface of the computer terminal 10 (or mobile device).

Here, it should be noted that in some alternative embodiments, the computer device (or mobile device) shown in fig. 2 described above may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that fig. 2 is only one example of a particular specific example and is intended to illustrate the types of components that may be present in the computer device (or mobile device) described above.

The present application operates a key update method as shown in fig. 3 under the above-described operating environment. Fig. 3 is a flowchart of a key updating method according to an embodiment of the present application, which is applied to a mobile terminal, and the mobile terminal can be implemented based on the computer terminal of fig. 2.

Referring to fig. 3, the method is applied to a mobile terminal, and the key updating method may include:

step S302: initiating an access request to a target server by using a first token issued by an issuing organization, wherein the first token is encrypted by using a first private key corresponding to a first public key;

in an alternative scheme, the issuing authority exists independently from the target server, the issuing authority is configured to generate an asymmetric key pair, encrypt the token using a private key thereof, and the target server obtains a corresponding public key, so that the public key can be used to verify the token encrypted using the private key. To further increase security, the issuing authority periodically updates the asymmetric key pair, for example, when the key pair is updated with the first private key and the first public key. When the target server cannot obtain the latest public key, i.e. the first public key, due to problems such as offline, it cannot verify the token encrypted with the first private key. The mobile terminal and the target server can establish local area network connection in the same local area network, and can also establish connection through near field communication technologies such as NFC, Bluetooth and ZigBee. The step S302 may be triggered by detecting that the target server is offline, may be triggered periodically, or may be triggered by a user or an administrator.

Step S304: receiving a response that the target server verifies the first token using the local public key, wherein the target server is configured to package an identification of the local public key in the response when the token verification is invalid;

in an optional scheme, the target server stores the obtained local public key, where the local public key may be obtained by the target server online or obtained by updating through the mobile terminal. When the issuing authority updates the asymmetric key pair and encrypts the token by using the updated private key, and the mobile terminal uses the token to send an access request to the target server, if the target server cannot acquire the latest public key due to problems such as offline, the target server verifies that the token is invalid. In one scheme, when the mobile terminal initiates an access request to the target server by using the first token, the mobile terminal does not know whether the local public key in the target server can verify the token, so that when the target server verifies the token inefficiently, the identification of the local public key is packaged in a response, and when the target server verifies the token effectively, the mobile terminal directly returns the resource indicated by the request. The identification of the local public key, for example, the id of the public key or the public key itself, is sufficient if the public key can be uniquely and certainly indicated.

Step S306: and analyzing the response, and acquiring a second token issued by the issuing organization when the response indicates that the verification is invalid, wherein the second token is encrypted by using a second private key corresponding to the local public key, and the first public key is packaged in the second token.

In an alternative arrangement, the second private key matches the local public key and is used when the issuing authority does not renew the key pair. The mobile terminal may obtain the second token in a variety of ways, for example, sending a token request to the issuing authority to request the issuing authority to issue the second token, and for example, the mobile terminal stores a plurality of tokens issued by the issuing authority and only needs to read the tokens from the tokens. In one scheme, an issuing organization receives a token request sent by a mobile terminal, reads an identifier of a local public key of a target server from the token request, and obtains a private key corresponding to the local public key, namely the second private key, according to the identifier. The mobile terminal program establishes connection with the issuing and issuing organization through the internet, the identification of the local public key of the target server is packaged in a token request and sent to the issuing organization, the issuing organization is requested to issue a new token for the issuing organization by using a private key corresponding to the local public key which is not updated, namely a second private key, and meanwhile, the updated public key, namely a first public key, is packaged in the new token.

Step S308: and initiating an access request to the target server by using the second token so that the target server verifies that the second token is valid by using the local public key, and updating the local public key into the first public key packaged in the second token so as to enable the target server to be accessed by the first token.

In an optional scheme, an old local public key in the target server is matched with the second private key, so that the second token can be verified to be valid, at this time, the first public key is read from the second token in the target server, and the local public key is updated by using the first public key, so that the updating of the local public key is realized.

Optionally, obtaining the second token issued by the issuing authority when the response indicates that the verification is invalid comprises:

initiating a second token issuing request to the issuing authority, wherein the second token issuing request comprises the identification of the local public key,

and receiving a second token returned by the issuing authority, wherein the issuing authority is configured to package the first public key in the second token and encrypt the second token by using a second private key corresponding to the local public key.

In an optional scheme, the issuing authority receives a token request sent by the mobile terminal, reads an identifier of the local public key of the target server from the token request, and obtains a private key corresponding to the local public key, that is, the second private key, according to the identifier. The mobile terminal program establishes connection with the issuing and issuing organization through the internet, the identification of the local public key of the target server is packaged in a token request and sent to the issuing organization, the issuing organization is requested to issue a new token for the issuing organization by using a private key corresponding to the local public key which is not updated, namely a second private key, and meanwhile, the updated public key, namely a first public key, is packaged in the new token.

determining a second private key corresponding to the local public key according to the identification of the local public key,

and searching a second token encrypted by using a second private key from a plurality of tokens locally stored in the mobile terminal, wherein the first public key is packaged in the second token.

Corresponding to the above steps, the issuing authority needs to be configured so that it actively sends the first token encrypted by the new private key (i.e. the verification token for authentication) and the second token wrapped with the new public key and encrypted by the old private key (i.e. the update token for updating the secret key) to the mobile terminal after each time the secret key pair is updated.

Based on the above method, an issuing authority is configured; when the key pair is updated, a first token (verification token) encrypted by using a new private key and a second token (updating token) wrapped with a new public key and encrypted by using an old private key are issued to the mobile terminal, wherein the first token is used for enabling the mobile terminal to initiate an access request to a target server, and the second token is used for enabling the mobile terminal to update a local public key in the target server.

The embodiment of the present application further provides a key updating method, applied to an issuing organization, including:

updating the key pair to obtain a new private key and a new public key;

generating a first token, wherein the first token is encrypted with the new private key;

generating a second token, wherein the second token is encrypted with an old private key and wherein the new public key is packaged;

issuing the first token and the second token to a mobile terminal, wherein the mobile terminal is configured to: and initiating an access request to a target server by using the first token, receiving a response of the target server for verifying the first token by using a local public key, and initiating an access request to the target server by using the second token when the response indicates that the verification is invalid because the local public key of the target server is an old public key, so that the target server verifies that the second token is valid by using the old public key, and updates the local public key to a new public key packaged in the second token.

For convenience of description, the verification token is used to represent the token encrypted by using the new private key after updating, the update token is used to represent the token encrypted by using the old private key before updating, and the update token is packaged with the new public key.

updating the key pair to obtain a new private key and a new public key;

generating a verification token, wherein the verification token is encrypted with the new private key;

generating an update token, wherein the update token is encrypted with an old private key and wherein a new public key is packaged;

issuing an authentication token and an update token to the mobile terminal, wherein the mobile terminal is configured to: and initiating an access request to a target server by using the verification token, receiving a response of the target server for verifying the verification token by using a local public key, and initiating an access request to the target server by using the update token when the response indicates that the verification is invalid because the local public key of the target server is an old public key, so that the target server verifies that the second token is valid by using the old public key, and updates the local public key into a new public key packaged in the update token.

In the above scheme, in the case that the mobile terminal fails to access the target server whose local public key is the old public key using the authentication token, the target server is successfully accessed using the update token, and the local public key in the target server is updated using the new public key packaged in the update token.

The specific issuing process is as follows:

the issuing organization generates a key pair for the first time to obtain a public key 0 and a private key 0, the private key 0 is used for encryption to obtain a verification token 0, if the target server is not offline, the local public key is updated to the public key 0, and the verification token 0 is issued to the mobile terminal;

the issuing organization updates the key pair for the first time to obtain a public key 1 and a private key 1, the private key 1 is used for encryption to obtain a verification token1, the public key 1 is packaged and the private key 0 is used for encryption to obtain an update token 0 ', and the verification token1 and the update token 0' are issued to the mobile terminal;

the issuing organization updates the key pair for the second time to obtain a public key 2 and a private key 2, the private key 2 is used for encryption to obtain a verification token2, the public key 2 is packaged and the private key 1 is used for encryption to obtain an update token1 ', the verification token2 and the update token 1' are issued to the mobile terminal, and the update token stored in the mobile terminal comprises the following steps: update token 0 ', update token 1'.

The issuing organization updates the key pair for the third time to obtain a public key 3 and a private key 3, the private key 3 is used for encryption to obtain a verification token 3, the public key 3 is packaged and the private key 2 is used for encryption to obtain an update token2 ', the verification token 3 and the update token 2' are issued to the mobile terminal, and the update token stored in the mobile terminal comprises the following steps: update token 0 ', update token1 ', update token2 '.

And so on.

The issuing organization updates the key pair for the Nth time to obtain a public key N and a private key N, at the moment, the private key N is used for encryption to obtain a verification token N, the public key N is packaged and encrypted by a private key N-1 to obtain an update token N-1 ', the verification token N and the update token N-1' are issued to the mobile terminal, and at the moment, the update token stored in the mobile terminal comprises: update token 0 ', update token 1', update token2 ', … …, update token N-1'.

The mobile terminal accesses the target server by using the latest verification token, namely the verification token N, if the target server is not offline, the local public key stored in the target server is the public key N, and the token N can be verified; if the target server is offline, the local public key stored therein may be any one of public keys 0 to N.

For example, when the target server is offline for a long time, assuming that the local public key stored therein is the oldest public key 0, the verification thereof for the token N is invalid, and the mobile terminal is informed that the local public key stored therein is the public key 0, at this time, the mobile terminal finds the update token 0 'corresponding to the public key 0 from the plurality of stored update tokens, and from the above analysis, the update token 0' is encrypted with the private key 0, and the public key 1 is packaged therein, the mobile terminal accesses the target server with the update token 0 ', and the target server can verify the update token 0' with the public key 0 'and replace the local public key 0 with the public key 1 packaged in the update token 0'.

Continuing the above example, the mobile terminal accesses the target server again using the latest verification token, that is, the verification token N, and since the local public key in the target server is updated to the public key 1, the token N still cannot be verified, at this time, the mobile terminal finds the update token1 ' corresponding to the public key 1 from the plurality of stored update tokens, and it can be known from the above analysis that the update token1 ' is encrypted using the private key 1 and is packaged with the public key 2, then the mobile terminal accesses the target server using the update token1 ', and the target server can verify the update token1 ' using the public key 1 and replace the local public key 1 with the public key 2 packaged in the update token1 '.

And the above steps are circularly executed for a plurality of times, the local public key in the target server is gradually replaced by the public key 3 and the public key 4 … …, and when the local public key in the target server is updated to the public key N, the token N can be verified, so that the mobile terminal can access the resource in the target server by adopting the token N.

According to the method, the issuing mechanism does not need to be requested for tokens for multiple times, and only needs to be configured, so that the issuing mechanism sends the token encrypted by using the new private key (namely the verification token for identity verification) and the token encrypted by using the old private key (namely the updating token for updating the secret key) wrapped with the new public key to the mobile terminal for storage every time the secret key pair is updated, and even if the target server misses updating of multiple rounds of secret key pairs, the local public key can be gradually updated to the latest through the mobile terminal.

Optionally, after updating the local public key to the first public key packaged in the second token, the method further includes:

initiating an access request to a target server by using a first token issued by an issuing organization;

the target server verifies that the first token is valid by using the updated local public key;

the target server returns the resource indicated by the access request.

In the above scheme, the local key in the target server has been updated to the public key in the issuer update key pair, so that the token encrypted by the new private key can pass authentication, and thus the target server can be accessed. The execution subject of the above steps may be the above mobile terminal, or may be a client on other devices.

Optionally, before initiating the access request to the target server using the first token issued by the issuing authority, the method further comprises:

monitoring whether a target server is online;

and when the target server is monitored to be offline, triggering the mobile terminal to establish local area network connection with the target server so as to initiate an access request to the target server through the mobile terminal.

In the above scheme, the mobile terminal is used to establish a connection with the target server after the target server is detected to be offline, so that the local public key in the target server is updated through the mobile terminal. In another alternative, the mobile terminal may always establish a connection with the target server, the mobile terminal sends an access request by using the first token issued by the issuing authority when the resource of the target server needs to be accessed, when the local key in the target server is the latest public key, the target server verifies that the first token is valid, the mobile terminal may normally access the target server, when the issuing authority updates the key pair and the local public key in the target server is not updated, the target server verifies that the first token is invalid, and at this time, the aforementioned key updating method may be executed to update the local public key in the target server.

Optionally, after the mobile terminal establishes a local area network connection with the target server, the method further includes:

the mobile terminal establishes connection with an issuing mechanism;

the mobile terminal verifies the validity of the issuing mechanism;

after the mobile terminal verifies that the issuing mechanism is valid, the mobile terminal logs in the issuing mechanism through a pre-stored user name and password so as to trigger the issuing mechanism to issue a token.

Optionally, the first token and the second token are asymmetric JWT tokens.

The JWT contains three parts of data:

a Header: header, typically the header has two pieces of information: a declaration type and an encryption algorithm;

payload: the payload section, or payload section, is the payload data, which typically contains the following information: user identity information and registration statements;

signature: the signature unit is authentication information of the entire data. The header and payload are encoded by base64, typically based on the data of the first two steps, plus the service's key is generated by an encryption algorithm (RSA algorithm encrypts and cannot be tampered with). For verifying the integrity and authenticity of the entire data.

Optionally, the target server verifying the first token using the local public key comprises:

reading a public key required for verification from a header of the first token;

judging whether the local public key is consistent with the read public key required by verification;

if yes, the target server verifies that the first token is valid;

if not, the target server verifies that the first token is invalid.

Optionally, packaging the first public key in the second token comprises: the first public key is written into the payload of the second token.

FIG. 4 is a flow chart of JWT based authentication according to an embodiment of the present application; as shown in fig. 4, the target server S (or called target server program or called network device) S and the issuing organization a are independent entities, and when the target server S disconnects the network and loses communication with the issuing organization a, the mobile terminal such as a mobile phone is used as a communication bridge to update the public key for the target server S or the device S. The specific process comprises the following steps:

1. and the mobile terminal program M accesses the Internet through 4G or other networks, accesses a public server of the token issuing organization A, and verifies the identity validity of the A through the server domain name and the security certificate.

2. And after the mobile terminal program M logs in the A through a user name, a password or other identity authentication modes approved by the A, the A issues an asymmetric JWT token.

3. The mobile terminal program M requests the server of the issuing agency a to acquire the latest signature verification public key kid _ n.

4. The mobile terminal program M uses the token issued by the new private key of A in the step 2 to request the target server S, the S identifies the public key required for signature verification through kid of a JOSE header part in JWT, finds that the new public key kid _ n does not exist locally, and then the S sends response information to the mobile terminal program M to inform that identity verification cannot be completed and prompts that kid currently used by S per se is kid _ S.

5. The mobile terminal program M is connected with a server of the request issuing organization A through the Internet, and requires the A to issue a new JWT token for the A by using a private key corresponding to kid _ s. The payload portion of the token contains the new signature verification public key kid _ n.

6. The mobile terminal program M requests the target service program S again using the token of step 5. Since token is issued for the old private key, the server program S can complete verification and successfully receive the new public key in the payload.

7. And (3) the mobile terminal program M continues to use the token in the step (2) to continue to request the target server S, and the S already acquires a new public key at the moment, so that the identity authentication can be successfully completed.

In an alternative, the above step 2 and step 4 are combined, that is, when the mobile terminal program logs in a, the token1 required for logging in S and the token2 required for updating S public key are issued at the same time, but since the public key held by the target service S cannot be determined (possibly expired for a long time), the token2 can be issued by simply using the last expired private key.

In an alternative, when the mobile terminal M does not have the internet condition in step 4, after the local security authentication can be completed through the administrator user and the password of the target device S, the new public key sent by M is received by S, which is relatively low in security.

In an alternative, in step 3, the latest signature verification public key can be obtained in real time by using message pushing of the mobile device

For example, in a specific scenario, in a local area network environment, there are a network device S (corresponding to the target server S in the solution), a mobile phone installed with a mobile App M (corresponding to the mobile program M in the solution), and a cloud server a (corresponding to the issuing organization a in the solution). At the moment, the network equipment S cannot be connected with the network, but the mobile phone provided with the mobile terminal App M can be connected with the 4G network; the cloud server a has updated the key pair. The network device S, the mobile terminal App M and the cloud server A use asymmetric encryption. The authentication procedure of JWT including the key update procedure includes:

1. and the mobile terminal App M accesses the cloud server A through the 4G network and verifies the validity of the A according to the domain name and the security certificate.

2. A user inputs a user name and a password in App M to log in a cloud server A, and the server A issues an asymmetric JWT token _ X by using a private key P _ key.

3. App M requests the cloud server a to obtain the latest signature verification public key kid _ n.

4. The App M requests the network device S by using JWT token _ X issued by a private key P _ key, a public key paired with the private key is kid _ n, the network device S identifies the public key required for signature verification through kid of a Jose Header part in JWT and finds that the public key is not available locally, and then the network device S sends response information to the App M to inform that identity verification cannot be completed and prompt that the public key currently used by the network device S is kid _ S.

5. The App M requests the cloud server A through 4G network connection, and the cloud server A is required to issue a new JWT token _ Y for the cloud server A by using a private key P _ key _1 corresponding to a public key kid _ s, wherein the payload part of the JWT token _ Y comprises a signature verification public key kid _ n.

6. App M requests network device S again using JWT token _ Y. Since the JWT token _ Y is issued by the old private key P _ key _1, the network device S can complete the verification and successfully receive the new public key kid _ n in the payload.

And 7, the App M continues to use the JWT token _ X to request the network equipment S, and the S already acquires a new public key kid _ n at the moment, can successfully complete the identity verification and displays the data to be accessed by the user.

By the scheme, when the network equipment S is offline, the public key can be updated for the network equipment S by taking a mobile terminal such as a mobile phone as a bridge; the mobile App M acquires a new JWT token from the cloud server through the 4G network, the payload part of the token contains a new signature verification public key, and when the App M uses the new JWT token again to request the network device S, the network device S can complete verification and successfully receive the new public key in the payload. Guest authentication can also be accomplished using an asymmetrically encrypted token even when the target service or device S is offline.

It should be noted that, for simplicity of description, the above-mentioned method embodiments are described as a series of acts or combination of acts, but those skilled in the art will recognize that the present application is not limited by the order of acts described, as some steps may occur in other orders or concurrently depending on the application. Further, those skilled in the art should also appreciate that the embodiments described in the specification are preferred embodiments and that the acts and modules referred to are not necessarily required in this application.

Through the above description of the embodiments, those skilled in the art can clearly understand that the key updating method according to the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but the former is a better implementation mode in many cases. Based on such understanding, the technical solutions of the present application may be embodied in the form of a software product, which is stored in a storage medium (e.g., ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal device (e.g., a mobile phone, a computer, a server, or a network device) to execute the method of the embodiments of the present application.

Example 2

According to an embodiment of the present application, an embodiment of a key updating method is also provided, where fig. 5 shows a flowchart of the key updating method, which is applied to a target server, where the target server may be implemented based on the computer terminal of fig. 2.

Referring to fig. 5, the method includes:

step S502: receiving an access request initiated by the mobile terminal by using a first token, wherein the first token is issued by an issuing organization and is encrypted by using a first private key corresponding to a first public key;

Step S504: verifying whether the first token is valid using the local public key;

in an optional scheme, the target server stores the obtained local public key, where the local public key may be obtained by the target server online or obtained by updating through the mobile terminal. When the issuing authority updates the asymmetric key pair and encrypts the token by using the updated private key, and the mobile terminal uses the token to send an access request to the target server, if the target server cannot acquire the latest public key due to problems such as offline, the target server verifies that the token is invalid.

Step S506: if the verification is invalid, sending a response of the identifier packaged with the local public key to the mobile terminal so that the mobile terminal can acquire a second token issued by an issuing organization, wherein the second token is encrypted by using a second private key corresponding to the local public key, and the first public key is packaged in the second token;

in an alternative scheme, when the mobile terminal initiates an access request to the target server by using the first token, it does not know whether the local public key in the target server can verify the token, so that when the target server verifies the token inefficiently, the identifier of the local public key is packaged in a response, and when the target server verifies the token effectively, the resource indicated by the request is directly returned. The identification of the local public key, for example, the id of the public key or the public key itself, is sufficient if the public key can be uniquely and certainly indicated. The second private key is matched with the local public key and is used when the issuing organization does not update the key pair. The mobile terminal may obtain the second token in a variety of ways, for example, sending a token request to the issuing authority to request the issuing authority to issue the second token, and for example, the mobile terminal stores a plurality of tokens issued by the issuing authority and only needs to read the tokens from the tokens. In one scheme, an issuing organization receives a token request sent by a mobile terminal, reads an identifier of a local public key of a target server from the token request, and obtains a private key corresponding to the local public key, namely the second private key, according to the identifier. The mobile terminal program establishes connection with the issuing and issuing organization through the internet, the identification of the local public key of the target server is packaged in a token request and sent to the issuing organization, the issuing organization is requested to issue a new token for the issuing organization by using a private key corresponding to the local public key which is not updated, namely a second private key, and meanwhile, the updated public key, namely a first public key, is packaged in the new token.

Step S508: receiving an access request initiated by the mobile terminal by using the second token;

step S510: and verifying that the second token is valid by using the local public key, and updating the local public key into the first public key packaged in the second token so as to enable the target server to be accessed through the first token.

Corresponding to the above steps, the issuing authority needs to be configured so that it actively sends the token encrypted by the new private key (i.e. the verification token for authentication) and the token wrapped with the new public key and encrypted by the old private key (i.e. the update token for updating the secret key) to the mobile terminal after each time the secret key pair is updated.

Based on the above method, an issuing authority is configured; and when the key pair is updated, issuing a verification token encrypted by using the new private key and an update token wrapped with the new public key and encrypted by using the old private key to the mobile terminal, wherein the verification token is used for enabling the mobile terminal to initiate an access request to the target server, and the update token is used for enabling the mobile terminal to update the local public key in the target server.

updating the key pair to obtain a new private key and a new public key;

and issuing a verification token and an update token to the mobile terminal so as to successfully access the target server by using the update token under the condition that the mobile terminal fails to access the target server of which the local public key is the old public key by using the verification token, and updating the local public key in the target server by using the new public key packaged in the update token.

The specific issuing process is as follows:

And so on.

the target server returns the resource indicated by the access request.

monitoring whether a target server is online;

the mobile terminal establishes connection with an issuing mechanism;

the mobile terminal verifies the validity of the issuing mechanism;

Optionally, the first token and the second token are asymmetric JWT tokens.

The JWT contains three parts of data:

if yes, the target server verifies that the first token is valid;

if not, the target server verifies that the first token is invalid.

Example 3

According to an embodiment of the present application, an embodiment of a key updating method is further provided, where fig. 6a and fig. 6b both show a flowchart of the key updating method, the method is applied to an issuing authority, and the issuing authority may be implemented based on the computer terminal of fig. 2.

As shown in fig. 6a, the key update method includes:

step Sa 602: updating the key pair, and encrypting the first token by using the updated first private key corresponding to the first public key;

in an alternative scheme, the issuing authority exists independently from the target server, the issuing authority is configured to generate an asymmetric key pair, encrypt the token using a private key thereof, and the target server obtains a corresponding public key, so that the public key can be used to verify the token encrypted using the private key. To further increase security, the issuing authority periodically updates the asymmetric key pair, for example, when the key pair is updated with the first private key and the first public key.

Step Sa 604: issuing a first token to the mobile terminal, so that the mobile terminal initiates an access request to a target server by using the first token, wherein the target server is configured to verify the first token by using a local public key, and package an identifier of the local public key in a response and return the identifier to the mobile terminal when the verification is invalid;

in an alternative, when the target server cannot obtain the latest public key, i.e. the first public key, due to a problem such as offline, it cannot verify the token encrypted using the first private key. The mobile terminal and the target server can establish local area network connection in the same local area network, and can also establish connection through near field communication technologies such as NFC, Bluetooth and ZigBee. When the issuing authority updates the asymmetric key pair and encrypts the token by using the updated private key, and the mobile terminal uses the token to send an access request to the target server, if the target server cannot acquire the latest public key due to problems such as offline, the target server verifies that the token is invalid. In one scheme, when the mobile terminal initiates an access request to the target server by using the first token, the mobile terminal does not know whether the local public key in the target server can verify the token, so that when the target server verifies the token inefficiently, the identification of the local public key is packaged in a response, and when the target server verifies the token effectively, the mobile terminal directly returns the resource indicated by the request. The identification of the local public key, for example, the id of the public key or the public key itself, is sufficient if the public key can be uniquely and certainly indicated.

Step Sa 606: receiving a second token issuing request sent by the mobile terminal, wherein the second token issuing request comprises an identifier of a local public key;

step Sa 608: packaging the first public key in a second token, and encrypting the second token by using a second private key corresponding to the local public key;

Step Sa 610: and issuing a second token to the mobile terminal, so that the mobile terminal initiates an access request to the target server by using the second token, so that the target server verifies that the second token is valid by using the local public key, and updates the local public key into a first public key packaged in the second token, thereby enabling the target server to be accessed by the first token.

As shown in fig. 6b, the key update method includes:

step Sb 602: updating the key pair to obtain a new private key and a new public key;

step Sb 604: generating a first token, wherein the first token is encrypted with the new private key;

step Sb 606: generating a second token, wherein the second token is encrypted with an old private key and wherein the new public key is packaged;

step Sb 608: issuing the first token and the second token to a mobile terminal, wherein the mobile terminal is configured to: and initiating an access request to a target server by using the first token, receiving a response of the target server for verifying the first token by using a local public key, and initiating an access request to the target server by using the second token when the response indicates that the verification is invalid because the local public key of the target server is an old public key, so that the target server verifies that the second token is valid by using the old public key, and updates the local public key to a new public key packaged in the second token.

updating the key pair to obtain a new private key and a new public key;

The specific issuing process is as follows:

And so on.

The method shown in fig. 6a is that the mobile terminal requests the issuing authority to issue the second token, and the method shown in fig. 6b is that the issuing authority actively issues the second token to the mobile terminal after updating the key pair each time, so that a plurality of update tokens are stored in the mobile terminal.

the target server returns the resource indicated by the access request.

monitoring whether a target server is online;

the mobile terminal establishes connection with an issuing mechanism;

the mobile terminal verifies the validity of the issuing mechanism;

Optionally, the first token and the second token are asymmetric JWT tokens.

The JWT contains three parts of data:

if yes, the target server verifies that the first token is valid;

if not, the target server verifies that the first token is invalid.

Example 4

According to an embodiment of the present application, there is also provided a key update apparatus for implementing the key update method, where the apparatus is implemented in a mobile terminal in a software or hardware manner, and the mobile terminal may be implemented based on the computer terminal in fig. 1.

As shown in fig. 7, the key update apparatus 700 includes: a first requesting unit 7002, a receiving unit 7004, an analyzing unit 7006, and a second requesting unit 7008, wherein:

a first request unit 7002, configured to initiate an access request to a target server using a first token issued by an issuing authority, where the first token is encrypted using a first private key corresponding to a first public key;

a receiving unit 7004, configured to receive a response that the target server verifies the first token using the local public key, where the target server is configured to package an identification of the local public key in the response when the token verification is invalid;

the parsing unit 7006 is configured to parse the response, and obtain a second token issued by the issuing authority when the response indicates that the verification is invalid, where the second token is encrypted by using a second private key corresponding to the local public key, and the first public key is packaged in the second token;

a second requesting unit 7008, configured to initiate an access request to the target server using the second token, so that the target server verifies that the second token is valid using the local public key, and update the local public key to the first public key packaged in the second token, so that the target server can be accessed through the first token.

Here, it should be noted that the first requesting unit 7002, the receiving unit 7004, the analyzing unit 7006, and the second requesting unit 7008 correspond to steps S302 to S308 in embodiment 1, and the four modules are the same as the corresponding steps in the implementation example and application scenarios, but are not limited to the disclosure in embodiment 1. It should be noted that the above modules may be operated in the computer terminal 10 provided in embodiment 1 as a part of the apparatus.

Optionally, the parsing unit 7006 is further configured to: and initiating a second token issuing request to the issuing organization, wherein the second token issuing request comprises the identification of the local public key, receiving a second token returned by the issuing organization, and the issuing organization is configured to pack the first public key in the second token and encrypt the second token by using a second private key corresponding to the local public key.

Optionally, the parsing unit 7006 is further configured to: and determining a second private key corresponding to the local public key according to the identification of the local public key, and searching a second token encrypted by using the second private key from a plurality of tokens locally stored in the mobile terminal, wherein the first public key is packaged in the second token.

Corresponding to the above scheme, the issuing authority needs to be configured so that it actively sends the token encrypted by the new private key (i.e. the verification token for authentication) and the token wrapped with the new public key and encrypted by the old private key (i.e. the update token for updating the secret key) to the mobile terminal after each time the secret key pair is updated.

Based on the above scheme, the issuing authority is configured to; and when the key pair is updated, issuing a verification token encrypted by using the new private key and an update token wrapped with the new public key and encrypted by using the old private key to the mobile terminal, wherein the verification token is used for enabling the mobile terminal to initiate an access request to the target server, and the update token is used for enabling the mobile terminal to update the local public key in the target server.

The specific issuing process of the issuing organization is as follows:

And so on.

Optionally, the apparatus is further configured to:

the target server returns the resource indicated by the access request.

Optionally, the apparatus is further configured to: monitoring whether the target server is online or not before initiating an access request to the target server by using a first token issued by an issuing agency; and when the target server is monitored to be offline, triggering the mobile terminal to establish local area network connection with the target server so as to initiate an access request to the target server through the mobile terminal.

Optionally, the apparatus is further configured to: after the mobile terminal establishes a local area network connection with the target server,

the mobile terminal establishes connection with an issuing mechanism;

the mobile terminal verifies the validity of the issuing mechanism;

Optionally, the first token and the second token are asymmetric JWT tokens.

The JWT contains three parts of data:

if yes, the target server verifies that the first token is valid;

if not, the target server verifies that the first token is invalid.

Example 5

According to an embodiment of the present application, there is also provided a key updating apparatus for implementing the key updating method, where the apparatus is implemented on a server side in a software or hardware manner, and the server may be implemented based on the computer terminal in fig. 1.

As shown in fig. 8, the key updating apparatus 800 includes: first request receiving unit 8002, first verifying unit 8004, response unit 8006, second request receiving unit 8008, second verifying unit 8010, wherein:

a first request receiving unit 8002, configured to receive an access request initiated by the mobile terminal using a first token, where the first token is issued by an issuing authority and is encrypted by using a first private key corresponding to the first public key;

a first verifying unit 8004, configured to verify whether the first token is valid using the local public key;

the response unit 8006, if the verification is invalid, sends a response packed with the identifier of the local public key to the mobile terminal, so that the mobile terminal obtains a second token issued by the issuing authority, where the second token is encrypted by using a second private key corresponding to the local public key, and the first public key is packed in the second token;

a second request receiving unit 8008, configured to receive an access request initiated by the mobile terminal using the second token;

a second verifying unit 8010 is configured to verify that the second token is valid by using the local public key, and update the local public key to the first public key packaged in the second token, so as to enable access to the target server through the first token.

Here, it should be noted that the first request receiving unit 8002, the first verifying unit 8004, the response unit 8006, the second request receiving unit 8008, and the second verifying unit 8010 correspond to steps S502 to S510 in embodiment 2, and the five modules are the same as examples and application scenarios realized by the corresponding steps, but are not limited to the contents disclosed in embodiment 1 or 2. It should be noted that the above modules may be operated in the computer terminal 10 provided in embodiment 1 as a part of the apparatus.

Optionally, the apparatus is further configured to, after updating the local public key to the first public key packaged in the second token,

the target server returns the resource indicated by the access request.

Optionally, the apparatus is further configured to, prior to initiating the access request to the target server using the first token issued by the issuing authority,

monitoring whether a target server is online;

the mobile terminal establishes connection with an issuing mechanism;

the mobile terminal verifies the validity of the issuing mechanism;

Optionally, the first token and the second token are asymmetric JWT tokens.

The JWT contains three parts of data:

if yes, the target server verifies that the first token is valid;

if not, the target server verifies that the first token is invalid.

Example 6

According to the embodiment of the present application, there is also provided a key updating apparatus for implementing the key updating method, where the apparatus is implemented at an issuing authority end in a software or hardware manner, and the issuing authority may be implemented based on the computer terminal in fig. 1.

As shown in fig. 9a, the key update apparatus 900 includes: an update unit 9002, a first token issuance unit 9004, a token request unit 9006, a token generation unit 9008, a second token issuance unit 9010, wherein:

an updating unit 9002, configured to update the key pair and encrypt the first token using the updated first private key corresponding to the first public key;

a first token issuing unit 9004, configured to issue a first token to the mobile terminal, so that the mobile terminal initiates an access request to a target server using the first token, where the target server is configured to verify the first token using a local public key, and package an identifier of the local public key in a response and return the response to the mobile terminal when the verification is invalid;

a token request unit 9006, configured to receive a second token issuance request sent by the mobile terminal, where the second token issuance request includes an identifier of the local public key;

a token generation unit 9008, configured to package the first public key in a second token, and encrypt the second token using a second private key corresponding to the local public key;

the second token issuing unit 9010 is configured to issue a second token to the mobile terminal, so that the mobile terminal initiates an access request to the target server by using the second token, so that the target server verifies that the second token is valid by using the local public key, and updates the local public key to the first public key packaged in the second token, so that the target server can be accessed by using the first token.

Here, the updating unit 9002, the first token issuing unit 9004, the token requesting unit 9006, the token generating unit 9008, and the second token issuing unit 9010 correspond to steps Sa602 to Sa610 in embodiment 3, and the five modules are the same as examples and application scenarios realized by the corresponding steps, but are not limited to the contents disclosed in embodiments 1 to 3. It should be noted that the above modules may be operated in the computer terminal 10 provided in embodiment 1 as a part of the apparatus.

As shown in fig. 9b, the key update apparatus 900 includes: an update unit 9012, a first token generation unit 9014, a second token generation unit 9016, and a token issuance unit 9018, wherein:

an updating unit 9012, configured to update the key pair to obtain a new private key and a new public key;

a first token generation unit 9014, configured to generate a first token, where the first token is encrypted with a new private key;

a second token generation unit 9016, configured to generate a second token, where the second token is encrypted with an old private key and a new public key is packaged;

a token issuance unit 9018 for issuing a verification token and an update token to the mobile terminal,

wherein the mobile terminal is configured to: and initiating an access request to a target server by using the first token, receiving a response of the target server for verifying the first token by using a local public key, and initiating an access request to the target server by using the second token when the response indicates that the verification is invalid because the local public key of the target server is an old public key, so that the target server verifies that the second token is valid by using the old public key, and updates the local public key to a new public key packaged in the second token.

Here, the update unit 9012, the first token generation unit 9014, the second token generation unit 9016, and the token issuance unit 9018 correspond to steps Sb602 to Sb608 in embodiment 3, and the four modules described above are the same as examples and application scenarios realized by the corresponding steps, but are not limited to those disclosed in embodiments 1 to 3. It should be noted that the above modules may be operated in the computer terminal 10 provided in embodiment 1 as a part of the apparatus.

The device shown in fig. 9a requests the issuing authority to issue the second token for the mobile terminal, and the device shown in fig. 9b actively issues the second token to the mobile terminal after the issuing authority updates the key pair each time, so that a plurality of update tokens are stored in the mobile terminal.

Optionally, after updating the local public key to the first public key packaged in the second token, the apparatus is further configured to implement:

the target server returns the resource indicated by the access request.

Optionally, before initiating the access request to the target server using the first token issued by the issuing authority, the apparatus is further configured to implement:

monitoring whether a target server is online;

Optionally, after the mobile terminal establishes the local area network connection with the target server, the apparatus is further configured to implement:

the mobile terminal establishes connection with an issuing mechanism;

the mobile terminal verifies the validity of the issuing mechanism;

Optionally, the first token and the second token are asymmetric JWT tokens.

The JWT contains three parts of data:

if yes, the target server verifies that the first token is valid;

if not, the target server verifies that the first token is invalid.

Example 7

Embodiments of the present application may provide a computing device, which may be any one of computer terminal devices in a computer terminal group. Optionally, in this embodiment, the computing device may also be replaced with a terminal device such as a mobile terminal.

Optionally, in this embodiment, the computing device may be located in at least one network device of a plurality of network devices of a computer network.

Optionally, in this embodiment, the above-mentioned computing device includes one or more processors, a memory, and a transmission device. The memory may be used to store software programs and modules, such as program instructions/modules corresponding to the key updating method and apparatus in the embodiments of the present application. The processor executes various functional applications and data processing by running software programs and modules stored in the memory, that is, the above-described key update method is realized.

Alternatively, the memory may include high speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory may further include memory located remotely from the processor, which may be connected to the computing device 120 over a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

In this embodiment, when the processor in the above-mentioned computing device runs the stored program code, the following method steps may be executed: initiating an access request to a target server by using a first token issued by an issuing organization, wherein the first token is encrypted by using a first private key corresponding to a first public key; receiving a response that the target server verifies the first token using the local public key, wherein the target server is configured to package an identification of the local public key in the response when the token verification is invalid; analyzing the response, and when the response indicates that the verification is invalid, acquiring a second token issued by the issuing organization, wherein the second token is encrypted by using a second private key corresponding to the local public key, and the first public key is packaged in the second token; and initiating an access request to the target server by using the second token so that the target server verifies that the second token is valid by using the local public key, and updating the local public key into the first public key packaged in the second token so as to enable the target server to be accessed by the first token.

In this embodiment, when the processor in the above-mentioned computing device runs the stored program code, the following method steps may be executed: receiving an access request initiated by the mobile terminal by using a first token, wherein the first token is issued by an issuing organization and is encrypted by using a first private key corresponding to a first public key; verifying whether the first token is valid using the local public key; if the verification is invalid, sending a response of the identifier packaged with the local public key to the mobile terminal so that the mobile terminal can acquire a second token issued by an issuing organization, wherein the second token is encrypted by using a second private key corresponding to the local public key, and the first public key is packaged in the second token; receiving an access request initiated by the mobile terminal by using the second token; and verifying that the second token is valid by using the local public key, and updating the local public key into the first public key packaged in the second token so as to enable the target server to be accessed through the first token.

In this embodiment, when the processor in the above-mentioned computing device runs the stored program code, the following method steps may be executed: updating the key pair, and encrypting the first token by using the updated first private key corresponding to the first public key; issuing a first token to the mobile terminal, so that the mobile terminal initiates an access request to a target server by using the first token, wherein the target server is configured to verify the first token by using a local public key, and package an identifier of the local public key in a response and return the identifier to the mobile terminal when the verification is invalid; receiving a second token issuing request sent by the mobile terminal, wherein the second token issuing request comprises an identifier of a local public key; packaging the first public key in a second token, and encrypting the second token by using a second private key corresponding to the local public key; and issuing a second token to the mobile terminal, so that the mobile terminal initiates an access request to the target server by using the second token, so that the target server verifies that the second token is valid by using the local public key, and updates the local public key into a first public key packaged in the second token, thereby enabling the target server to be accessed by the first token.

In this embodiment, when the processor in the above-mentioned computing device runs the stored program code, the following method steps may be executed: updating the key pair to obtain a new private key and a new public key; generating a first token, wherein the first token is encrypted with the new private key; generating a second token, wherein the second token is encrypted with an old private key and wherein the new public key is packaged; issuing the first token and the second token to a mobile terminal, wherein the mobile terminal is configured to: and initiating an access request to a target server by using the first token, receiving a response of the target server for verifying the first token by using a local public key, and initiating an access request to the target server by using the second token when the response indicates that the verification is invalid because the local public key of the target server is an old public key, so that the target server verifies that the second token is valid by using the old public key, and updates the local public key to a new public key packaged in the second token.

Further, in this embodiment, when the processor in the computing device runs the stored program code, any of the method steps listed in embodiments 1 to 3 may be executed, which is not described in detail herein for brevity.

Example 8

Embodiments of the present application also provide a storage medium. Optionally, in this embodiment, the storage medium may be configured to store a program code executed by the key updating method.

Optionally, in this embodiment, the storage medium may be located in any one of computer terminals in a computer terminal group in a computer network, or in any one of mobile terminals in a mobile terminal group.

Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: initiating an access request to a target server by using a first token issued by an issuing organization, wherein the first token is encrypted by using a first private key corresponding to a first public key; receiving a response that the target server verifies the first token using the local public key, wherein the target server is configured to package an identification of the local public key in the response when the token verification is invalid; analyzing the response, and when the response indicates that the verification is invalid, acquiring a second token issued by the issuing organization, wherein the second token is encrypted by using a second private key corresponding to the local public key, and the first public key is packaged in the second token; and initiating an access request to the target server by using the second token so that the target server verifies that the second token is valid by using the local public key, and updating the local public key into the first public key packaged in the second token so as to enable the target server to be accessed by the first token.

Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: receiving an access request initiated by the mobile terminal by using a first token, wherein the first token is issued by an issuing organization and is encrypted by using a first private key corresponding to a first public key; verifying whether the first token is valid using the local public key; if the verification is invalid, sending a response of the identifier packaged with the local public key to the mobile terminal so that the mobile terminal can acquire a second token issued by an issuing organization, wherein the second token is encrypted by using a second private key corresponding to the local public key, and the first public key is packaged in the second token; receiving an access request initiated by the mobile terminal by using the second token; and verifying that the second token is valid by using the local public key, and updating the local public key into the first public key packaged in the second token so as to enable the target server to be accessed through the first token.

Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: updating the key pair, and encrypting the first token by using the updated first private key corresponding to the first public key; issuing a first token to the mobile terminal, so that the mobile terminal initiates an access request to a target server by using the first token, wherein the target server is configured to verify the first token by using a local public key, and package an identifier of the local public key in a response and return the identifier to the mobile terminal when the verification is invalid; receiving a second token issuing request sent by the mobile terminal, wherein the second token issuing request comprises an identifier of a local public key; packaging the first public key in a second token, and encrypting the second token by using a second private key corresponding to the local public key; and issuing a second token to the mobile terminal, so that the mobile terminal initiates an access request to the target server by using the second token, so that the target server verifies that the second token is valid by using the local public key, and updates the local public key into a first public key packaged in the second token, thereby enabling the target server to be accessed by the first token.

Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: updating the key pair to obtain a new private key and a new public key; generating a first token, wherein the first token is encrypted with the new private key; generating a second token, wherein the second token is encrypted with an old private key and wherein the new public key is packaged; issuing the first token and the second token to a mobile terminal, wherein the mobile terminal is configured to: and initiating an access request to a target server by using the first token, receiving a response of the target server for verifying the first token by using a local public key, and initiating an access request to the target server by using the second token when the response indicates that the verification is invalid because the local public key of the target server is an old public key, so that the target server verifies that the second token is valid by using the old public key, and updates the local public key to a new public key packaged in the second token.

Further, in this embodiment, the storage medium is configured to store the program code for executing any one of the method steps listed in embodiments 1 to 3, which is not described in detail herein for reasons of brevity.

Example 9

According to an embodiment of the present application, there is also provided a key update system that can execute the key update method provided in embodiments 1 to 3, the system including: issue mechanism, mobile terminal and target server, wherein:

the issuing authority updates the key pair and issues a first token to the mobile terminal, wherein the first token is encrypted by using a first private key corresponding to the first public key after updating;

the mobile terminal initiates an access request to a target server by using a first token;

the target server verifies whether the first token is valid by using the local public key; if the verification is invalid, sending a response of the identifier packaged with the local public key to the mobile terminal;

the mobile terminal analyzes the response, and when the response indicates that the verification is invalid, a second token issued by the issuing organization is obtained, wherein the second token is encrypted by using a second private key corresponding to the local public key, and the first public key is packaged in the second token;

the mobile terminal initiates an access request to the target server by using the second token;

the target server uses the local public key to verify that the second token is valid, and updates the local public key to the first public key packaged in the second token, so that the target server can be accessed through the first token.

updating the key pair to obtain a new private key and a new public key;

The specific issuing process is as follows:

And so on.

the target server returns the resource indicated by the access request.

monitoring whether a target server is online;

the mobile terminal establishes connection with an issuing mechanism;

the mobile terminal verifies the validity of the issuing mechanism;

Optionally, the first token and the second token are asymmetric JWT tokens.

The JWT contains three parts of data:

if yes, the target server verifies that the first token is valid;

if not, the target server verifies that the first token is invalid.

The above-mentioned serial numbers of the embodiments of the present application are merely for description and do not represent the merits of the embodiments.

In the above embodiments of the present application, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.

In the embodiments provided in the present application, it should be understood that the disclosed technology can be implemented in other ways. The above-described embodiments of the apparatus are merely illustrative, and for example, a division of a unit is merely a division of a logic function, and an actual implementation may have another division, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, units or modules, and may be in an electrical or other form.

Units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed to by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method of the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic or optical disk, and other various media capable of storing program codes.

The foregoing is only a preferred embodiment of the present application and it should be noted that those skilled in the art can make several improvements and modifications without departing from the principle of the present application, and these improvements and modifications should also be considered as the protection scope of the present application.

Claims

1. A key updating method is applied to a mobile terminal and comprises the following steps:

initiating an access request to a target server by using a first token issued by an issuing organization, wherein the first token is encrypted by using a first private key corresponding to a first public key;

receiving a response that the target server verifies the first token using a local public key, wherein the target server is configured to package an identification of the local public key in the response when token verification is invalid;

analyzing the response, and acquiring a second token issued by an issuing organization when the response indicates that the verification is invalid, wherein the second token is encrypted by using a second private key corresponding to the local public key, and the first public key is packaged in the second token;

and initiating an access request to a target server by using the second token so that the target server verifies that the second token is valid by using the local public key, and updating the local public key into a first public key packaged in the second token so as to enable the target server to be accessed by the first token.

2. The method of claim 1, wherein obtaining the second token issued by the issuing authority when the response indicates that the verification is invalid comprises:

initiating a second token issuance request to the issuing authority, wherein the second token issuance request includes an identification of the local public key,

receiving a second token returned by the issuing authority, wherein the issuing authority is configured to package the first public key in the second token and encrypt the second token using a second private key corresponding to the local public key; or

and searching a second token encrypted by using the second private key from a plurality of tokens locally stored in the mobile terminal, wherein the first public key is packaged in the second token.

3. The method of claim 1, wherein after updating the local public key to the first public key packaged in the second token, the method further comprises:

and the target server returns the resource indicated by the access request.

4. The method of claim 1, wherein prior to initiating the access request to the target server using the first token issued by the issuing authority, the method further comprises:

monitoring whether a target server is online;

and when the situation that the target server is offline is monitored, triggering the mobile terminal to establish local area network connection with the target server so as to initiate the access request to the target server through the mobile terminal.

5. The method of claim 4, wherein after the mobile terminal establishes a local area network connection with the target server, the method further comprises:

the mobile terminal establishes connection with the issuing mechanism;

the mobile terminal verifies the validity of the issuing mechanism;

and after the mobile terminal verifies that the issuing mechanism is valid, logging in the issuing mechanism through a pre-stored user name and password so as to trigger the issuing mechanism to issue a token.

6. The method of any of claims 1-5, wherein the first and second tokens are asymmetric JWT tokens, and wherein the target server verifying the first token using a local public key comprises:

if yes, the target server verifies that the first token is valid;

if not, the target server verifies that the first token is invalid.

7. The method of claim 5, wherein packaging the first public key in the second token comprises: writing the first public key into a payload of the second token.

8. A key updating method is applied to a target server and comprises the following steps:

receiving an access request initiated by a mobile terminal by using a first token, wherein the first token is issued by an issuing organization and is encrypted by using a first private key corresponding to a first public key;

verifying whether the first token is valid using a local public key;

if the verification is invalid, sending a response packaged with the identifier of the local public key to the mobile terminal so that the mobile terminal can obtain a second token issued by an issuing organization, wherein the second token is encrypted by using a second private key corresponding to the local public key, and the first public key is packaged in the second token;

receiving an access request initiated by the mobile terminal by using the second token;

and verifying that the second token is valid by using a local public key, and updating the local public key into a first public key packaged in the second token so as to enable the target server to be accessed through the first token.

9. A key updating method is applied to an issuing organization, and comprises the following steps:

updating the key pair, and encrypting the first token by using the updated first private key corresponding to the first public key;

issuing the first token to a mobile terminal, so that the mobile terminal initiates an access request to a target server by using the first token, wherein the target server is configured to verify the first token by using a local public key, and package an identifier of the local public key in a response and return the identifier to the mobile terminal when the verification is invalid;

receiving a second token issuing request sent by the mobile terminal, wherein the second token issuing request comprises the identification of the local public key;

packaging the first public key in a second token, and encrypting the second token by using a second private key corresponding to the local public key;

and issuing the second token to the mobile terminal, so that the mobile terminal initiates an access request to a target server by using the second token, so that the target server verifies that the second token is valid by using the local public key, and updates the local public key into a first public key packaged in the second token, so that the target server can be accessed by using the first token.

10. A method for updating a key, comprising:

an issuing organization updates a key pair to obtain a new private key and a new public key, generates a first token and a second token, and issues the first token and the second token to a mobile terminal, wherein the first token is encrypted by the new private key, the second token is encrypted by an old private key, and the new public key is packaged;

receiving, by a mobile terminal, the first token and the second token, wherein the mobile terminal stores a plurality of first tokens and second tokens after the issuing authority updates a key pair for a plurality of times, the mobile terminal being configured to: the method comprises the steps of initiating an access request to a target server by using a first token which is received recently, receiving a response of the target server for verifying the first token which is received recently by using a local public key, searching a second token which is encrypted by using a first old private key corresponding to the first old public key when the response indicates that the verification is invalid due to the fact that the local public key of the target server is the first old public key, initiating the access request to the target server by using the searched second token, enabling the target server to verify that the searched second token is valid by using the first old public key, and updating the local public key to a new public key which is packaged in the searched second token.

11. A key update apparatus applied to a mobile terminal, comprising:

the system comprises a first request unit, a first server and a second request unit, wherein the first request unit is used for initiating an access request to a target server by using a first token issued by an issuing agency, and the first token is encrypted by using a first private key corresponding to a first public key;

a token receiving unit, configured to receive a response that the target server verifies the first token using a local public key, wherein the target server is configured to package an identification of the local public key in the response when token verification is invalid;

the analysis unit is used for analyzing the response and acquiring a second token issued by an issuing organization when the response indicates that the verification is invalid, wherein the second token is encrypted by using a second private key corresponding to the local public key, and the first public key is packaged in the second token;

and the second request unit is used for initiating an access request to a target server by using the second token so that the target server verifies that the second token is valid by using the local public key, and updates the local public key into the first public key packaged in the second token, so that the target server can be accessed by the first token.

12. A key update apparatus applied to a target server, comprising:

the mobile terminal comprises a first request receiving unit, a first processing unit and a second processing unit, wherein the first request receiving unit is used for receiving an access request initiated by the mobile terminal by using a first token, the first token is issued by an issuing organization, and the first token is encrypted by using a first private key corresponding to a first public key;

a first verifying unit configured to verify whether the first token is valid using a local public key;

a response unit, configured to send, to the mobile terminal, a response in which the identifier of the local public key is packaged if the verification is invalid, so that the mobile terminal obtains a second token issued by an issuing authority, where the second token is encrypted using a second private key corresponding to the local public key, and the first public key is packaged in the second token;

a second request receiving unit, configured to receive an access request initiated by the mobile terminal using the second token;

and the second verification unit is used for verifying that the second token is valid by using a local public key and updating the local public key into a first public key packaged in the second token so as to enable the target server to be accessed through the first token.

13. A key renewal apparatus applied to an issuing authority, comprising:

the updating unit is used for updating the key pair and encrypting the first token by using the updated first private key corresponding to the first public key;

the system comprises a first token issuing unit, a target server and a second token issuing unit, wherein the first token issuing unit is used for issuing the first token to the mobile terminal so that the mobile terminal initiates an access request to the target server by using the first token, the target server is configured to verify the first token by using a local public key, and package the identification of the local public key in a response and return the response to the mobile terminal when the verification is invalid;

a token request unit, configured to receive a second token issuance request sent by the mobile terminal, where the second token issuance request includes an identifier of the local public key;

the token generating unit is used for packaging the first public key in a second token and encrypting the second token by using a second private key corresponding to the local public key;

and the second token issuing unit is used for issuing the second token to the mobile terminal, so that the mobile terminal initiates an access request to a target server by using the second token, the target server verifies that the second token is valid by using the local public key, and the local public key is updated to the first public key packaged in the second token, so that the target server can be accessed by the first token.

14. A key update system, comprising an issuing authority, a mobile terminal and a target server, wherein:

15. A key update system, comprising an issuing authority, a mobile terminal and a target server, wherein:

the mobile terminal initiates an access request to a target server by using the first token;

the target server verifies whether the first token is valid by using a local public key; if the verification is invalid, sending a response packaged with the identifier of the local public key to the mobile terminal;

the mobile terminal analyzes the response, and when the response indicates that the verification is invalid, a second token issued by an issuing organization is obtained, wherein the second token is encrypted by using a second private key corresponding to a local public key, and the first public key is packaged in the second token;

the mobile terminal initiates an access request to a target server by using the second token;

and the target server verifies that the second token is valid by using the local public key and updates the local public key into the first public key packaged in the second token, so that the target server can be accessed through the first token.

16. A storage medium, characterized in that the storage medium comprises a stored program, wherein the device on which the storage medium is located is controlled to perform the method according to any of claims 1-9 when the program is run.

17. A computing device comprising a processor, wherein the processor is configured to execute a program, wherein the program when executed performs the method of any of claims 1-9.