CN111193592B - Public key updating method between double systems - Google Patents
Public key updating method between double systems Download PDFInfo
- Publication number
- CN111193592B CN111193592B CN201811352806.1A CN201811352806A CN111193592B CN 111193592 B CN111193592 B CN 111193592B CN 201811352806 A CN201811352806 A CN 201811352806A CN 111193592 B CN111193592 B CN 111193592B
- Authority
- CN
- China
- Prior art keywords
- public key
- updating
- public
- response
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
Abstract
The invention relates to a public key updating method between double systems, which is characterized by comprising the following steps: a query request step of initiating a public key query request from the first system to the second system; a query response step, wherein the second system returns a public key query response to the first system based on the public key query request; a public key update request step, wherein the first system judges whether the current public key needs to be updated based on the public key inquiry response and initiates a public key update request to the second system under the condition that the public key needs to be updated, wherein the public key update request contains the latest public key; and a public key update response step in which the second system updates the current public key based on the public key update request and returns a public key update response to the first system. According to the invention, the public key is not required to be carried by the message, so that the service efficiency of the system and the network can be improved.
Description
Technical Field
The invention relates to computer technology, in particular to a public key updating method between double systems.
Background
An asymmetric encryption algorithm based on public and private key pairs is needed among the existing online message systems to encrypt sensitive information (such as account numbers, passwords and the like) and ensure that the message information is not tampered. When one party (denoted as a system) upgrades its public and private key pair keypair_a1 to keypair_a2, the other party (denoted as B system) needs to be notified to synchronously upgrade the stored a system public key from publickey_a1 to publickey_a2.
The public key exchange mode between the existing online message systems generally mainly adopts the following two modes:
(1) Manual updating
The B system has stored publicKey_a1 in the system. When the A system upgrades the KeyPair_a1 to the KeyPair_a2, the A system informs B in a non-systematic way in an offline way, such as public, mail and the like. B system needs to obtain publicKey_a2 and load the publicKey_a2 into own system. When publickey_a2 is activated, publickey_a1 may be removed.
In this method, the system a updates its own public and private key pair, but the system B also needs to perform a manual change operation (acquire updated public key information and install it). If the B system fails to perform the update operation on time and the publickey_a1 is disabled, the message interaction between the a system and the B system is affected. After the A system notifies the updated public key, the B system needs to perform manual change operation, so that the operation is complicated.
(2) Decrypting directly using public key fields in the interaction message without storing the public key
The system B does not store public key information of the system A, the system A transmits the public key information to the system B every time the system A transmits a message to the system B, and the system B always uses the public key information in the received message to perform operations such as decryption, signature verification and the like when processing the message. When the A system updates the public key, only a new public key publicKey_a2 needs to be transmitted in the next message, the B system does not need any manual intervention, and the B system can directly use the public key information in the new message.
In this way, the system a needs to carry public key information each time when sending the message to the system B, so that the message length is greatly increased, and the interaction efficiency is affected. Meanwhile, the transmission mode is only suitable for verifying the signature and is not suitable for decrypting the information.
Disclosure of Invention
In view of the above, the present invention aims to provide a method for updating a public key between two systems, which does not require manual operation and also does not require each message to carry a public key.
The method for updating the public key between the two systems according to one aspect of the invention is characterized by comprising the following steps:
a query request step of initiating a public key query request from the first system to the second system;
a query response step, wherein the second system returns a public key query response to the first system based on the public key query request;
a public key update request step, wherein the first system judges whether the current public key needs to be updated based on the public key inquiry response and initiates a public key update request to the second system under the condition that the public key needs to be updated, wherein the public key update request contains the latest public key; and
and a public key update response step, wherein the second system updates the current public key based on the public key update request and returns a public key update response to the first system.
Optionally, a public key query request is issued from the first system to the second system according to a specified query period.
Optionally, the specified query period is set in a period of application link probing between the two systems.
Optionally, in the step of requesting public key update, the first system initiates a public key update request to the second system if the first system determines whether the current public key needs to be updated or the first system wants to need to update the current public key based on the query response.
Optionally, the public key inquiry request comprises a signature public-private key pair ID and an encryption public-private key pair ID of the second system,
the public key inquiry response comprises a signature public-private key pair ID and an encryption public-private key pair ID of the first system,
the public key update request comprises a signature public-private key pair ID and a signature public key value of the latest public key.
Optionally, the public key update response step is further set to:
setting the first system and the second system within a prescribed period enables use of one of the latest public key or the current public key.
Optionally, the public key update response step is further set to:
setting the first system and the second system within a prescribed period enables use of one of the latest public key or the current public key.
Optionally, after the public key update response step, further includes:
and an alarm prompting step, wherein if the public key updating response indicates that the updating is unsuccessful, an alarm prompt is sent after a preset set time.
The method for updating the public key between the two systems according to one aspect of the invention is characterized by comprising the following steps:
a query request step of initiating a public key query request from the first system to the second system;
a query updating step, wherein the second system returns a public key query response to the first system based on a public key query request, and meanwhile, when the second system judges whether the current public key needs to be updated based on the public key query request and returns a public key update request to the first system under the condition that the public key needs to be updated, the public key update request contains the latest public key; and
and an update result notification step, wherein the first system returns a second system update result after updating the public key based on the public key update request.
Optionally, the public key inquiry request comprises a signature public key ID and an encryption public key ID of the second system,
the public key inquiry response comprises a signature public key pair ID and an encryption public key pair ID of the first system, a latest signature public key pair ID and a latest signature public key value.
The method for updating the public key between the two systems according to one aspect of the invention is characterized by comprising the following steps:
a backup request step, namely initiating a public key backup request from a first system to a second system;
a backup response step, wherein the second system judges whether the public key needs to be updated based on the public key backup request and returns the judging result to the first system as a backup response;
a public key update request step, wherein the first system initiates a public key update request to the second system when the public key needs to be updated or the judgment result in the report response is that the public key needs to be updated, and the public key update request contains the latest public key; and
and a public key update response step, wherein the second system updates the current public key based on the public key update request and returns a public key update response to the first system.
A computer-readable storage medium according to an aspect of the present invention has a computer program stored thereon, wherein the program is executed by a processor to implement the above-described method for updating a public key between two systems.
The computer device according to an aspect of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned method for updating a public key between two systems when executing the program.
As described above, according to the method for updating the public key between the two systems, the update of the public key is realized by using the message interaction and processing mechanism between the systems, and when the first system (or A system) updates the public key, the second system (or B system) does not need to perform corresponding manual operation and processing. Moreover, each message does not need to carry a public key, so that the length of a normal message can be shortened, and the use efficiency of a system and a network can be improved. Moreover, the invention also provides a public key inquiry and backup mechanism, which can realize the link application detection function without developing related messages independently. In addition, the invention uses public key inquiry and report and double public key mechanism to realize higher system fault tolerance, when one party updates public and private key pair and initiates updating public key, if the other party system does not respond to environmental problem, it does not need manual processing and intervention, and can automatically realize updating in the next inquiry and report period.
Other features and advantages of the methods and apparatus of the present invention will be apparent from or elucidated with reference to the drawings, taken in conjunction with the accompanying drawings, and the detailed description which follows in conjunction with the accompanying drawings, serve to illustrate certain principles of the invention.
Drawings
Fig. 1 is a flow chart showing a method for updating a public key between two systems according to a first embodiment of the present invention.
Fig. 2 is a flow chart showing a method for updating a public key between two systems according to a second embodiment of the present invention.
Fig. 3 is a flow chart showing a method for updating a public key between two systems according to a third embodiment of the present invention.
Detailed Description
The following presents a simplified summary of the invention in order to provide a basic understanding of the invention. It is not intended to identify key or critical elements of the invention or to delineate the scope of the invention.
First, the idea of the method for updating a public key between two systems according to the present invention will be described. The system a and the system B (and the first system and the second system) mentioned in the present specification mean two different systems, which can be exchanged therebetween, and are not limited in any way.
In the invention, the method for updating the public key between the two systems can adopt periodic report or periodic inquiry. Specifically, during the service of the online systems of both parties, the system A periodically sends the self-stored Key Pair ID_bX (wherein the Key Pair ID represents the public and private key pair ID) of the system B to the system B through an online message. And B, the system judges whether the KeyPair ID_bX is consistent with the latest public and private key pair ID stored in the system. If not, an update request of publicKey_b (where publicKey represents the public key) is initiated to the A-system. And the B system sends the stored KeyPairidAX of the A system to the A system through an online message. And the system A automatically judges whether the public key pair is consistent with the latest public key pair stored in the system. If not, an update request of publicKey_a is initiated to the B system.
In the present invention, the public key is updated in an online message. Assuming that the system a updates its own keypair_a1 to keypair_a2 (where KeyPair represents a public-private key pair), the updated publickey_a2 and the updated keypair_a2 are sent to the system B by a message during online system service of both parties, and the system B performs system update after receiving the update result and responds to the update result.
In the present invention, a dual public key mechanism is also presented. For example, when the A system updates its own KeyPair_a1 to KeyPair_a2, and the B system has updated publicKey_a2 successfully. Both parties need to support the two public and private key pairs in a period of time at the same time, and the original public and private keys cannot be removed in the system. The original public-private key pair can be invalidated only when a specified condition is met, for example, the specified condition is as follows:
(1) The existing online message is normally encrypted and decrypted by using a new public key and a new private key, and the message is normally processed by both parties;
(2) There is a period of time, such as a specified number of days, after the key exchange is successful.
In the invention, a system alarm function is also provided. For example, if the system B fails to update the public key of system a for a long time and the number of days is set, the system a gives an alarm to remind operators of intervention.
For online message processing, for example, the a system transmits an encrypted public-private key pair ID, i.e., encryptionkeypair_b, and a signed public-private key pair, i.e., ID SignatureKeyPairID _a, used by the a system to the B system (where EncryptionKeyPair represents the encrypted public-private key pair ID represented by ID, signatureKeyPairID), and the B system may find the encrypted private key encryptionprivatekey_b stored in the B system to perform decryption according to the two IDs, and find the signed public key signaturepublic key_a to perform signature verification. In the invention, a public key update fault-tolerant mechanism is also provided. For example, various online tests and functional detection are performed before real message interaction occurs between online systems, so that exception handling does not include errors of coding, flow, functions, mechanisms and the like of software and hardware of the system, and only includes environment exceptions caused by network, system performance and the like, which are manifested as message loss, no response and the like. For example:
(1) Periodic backup and query failure: if the A system sends the message to the B system, the sending fails. Without any treatment, the process is continued the next day.
(2) Failure of online message update: if the system A updates the own Key Pair_a1 to Key Pair_a2 successfully, the updated message fails to be sent, or the feedback of the updating result of the system B is not received, the system A uses the Key Pair_a1 in the message sent to the system B, and uses the Key Pair ID transmitted by the system B to decrypt or check the signature when the message sent by the system B is received.
The dual key mechanism ensures that online transactions are not affected whether or not the B system is updated successfully publickey_a2. If the system B is updated successfully, the system A can find that the system B is updated successfully in the next inquiry and backup period for the public and private key pair, and then a new KeyPair_a2 is started to be used. If the system B fails to update, the system A will find that the system B fails to update in the next inquiry and backup period, and then send online message update and update again. If the updating of the system B fails in a continuous prescribed day, the system A prompts an operator A to coordinate the system B for processing through a system alarm mechanism.
In the present invention, it is also proposed to apply a link probing mechanism. For example, the periodic backup and inquiry messages are set in the period of applying link detection, so that the link detection function can be realized through the messages.
Next, an embodiment of the method for updating a public key between two systems according to the present invention will be described.
Fig. 1 is a flow chart showing a method for updating a public key between two systems according to a first embodiment of the present invention. In this first embodiment, a case example of periodic inquiry and public key update is shown.
As shown in fig. 1, the method for updating a public key between two systems according to the first embodiment includes the following steps:
query request step S11: a public key query request is initiated from a first system to a second system,
query response step S12: the second system returns a public key inquiry response to the first system based on the public key inquiry request;
public key update request step S13: the first system judges whether the current public key needs to be updated based on the public key inquiry response, and initiates a public key update request to the second system under the condition that the public key needs to be updated or the first system needs to update the public key, wherein the public key update request contains the latest public key; and
public key update response step S14: the second system updates the current public key based on the public key update request and returns a public key update response to the first system.
Next, a specific example will be described.
In the query request step S11, the first system initiates a public key query request to the second system, where the request carries the signature public key ID and the encryption public key ID of the second system. For example, "public key query request" is:
{“LatestSignatureKeyPairID”： “signature b1”， LatestEncryptionKeyPairID”：“encryption b1” } 。
in the query response step S12, the second system returns a public key query response to the first system, where the response carries the signature public key ID and the encryption public key ID of the first system. For example, "public key challenge response" is:
{“LatestSignatureKeyPairID”：“signature a1”，
“LatestEncryptionKeyPairID”：“encryption a1” } 。
in the public key update request step S13, when the first system needs to update the public key itself, or finds that the public key stored in the second system is not up to date in the public key query, a public key update request is initiated. For example, the "public key update request" is:
{ "UpdatedSignatureKeyPair ID": "signature a2", "updatedSignature public Key": public key value }.
In the public key update response step S14, the second system responds to the update result after updating the relevant public key of the first system. For example, "public key update response" is:
{ “UpdatedSignatureKeyPair ID”：“signature a2”， “ResponseCode”：“Success” }。
in the above example, the first system corresponds to "a", and the second system corresponds to "b" (hereinafter).
The second system may also initiate a public key query request to the first system, which will not be described in detail. And when the second system finds that the public key of the first system is not the latest public key carried in the public key inquiry request, the second system can also initiate public key update to the first system.
Wherein a public key inquiry request is sent from the first system to the second system according to a prescribed inquiry period. Here, the inquiry period is set to be within a period of application link probing between the two systems. If the long connection is applied for 12 hours, the period of initiation of the public key query may be 6 hours.
As an example, after the public key update response step S14, it is further set to: setting the first system and the second system within a prescribed period enables use of the latest public key or one of the current public keys. By using the double public key mechanism, both sides can support the two public and private key pairs in a period of time at the same time, and the original public and private keys cannot be removed in the system. For example, the original public-private key pair may be invalidated only when a prescribed condition is satisfied.
As an example, after the public key update response step S14, further includes: and in the alarm prompting step, if the public key updating response shows that the updating is unsuccessful, the steps S11-S14 can be repeated to update again, and the old public and private keys can be used for encrypting and signing the message during the updating, if the updating is unsuccessful after the preset specified time, the system alarms, sends an alarm prompt and notifies related personnel that the updating of the key fails.
The online transaction process continues after the public key is updated between the two systems.
The flow of online transaction processing is briefly described herein.
First, the first system sends an online message to the second system, where the online message includes a signed public-private key pair ID, a signature, an encrypted public-private key pair ID, encrypted data, etc., for example:
{ “SignatureKeyPair ID”：“signature a2”，
"Signature": signing
“EncryptionKeyPair ID”： “encryption b1”
"EncryptedData": encryption information, … … }.
Second, the second system verifies the signature with its stored Signature public Key_a2 and decrypts with encryptionPrivateKey_b1, and vice versa.
Fig. 2 is a flow chart showing a method for updating a public key between two systems according to a second embodiment of the present invention. In this second embodiment, an example in which a query response and an update request are fused together in a periodic query is shown.
As shown in fig. 2, the method for updating a public key between two systems according to the second embodiment includes the following steps:
query requesting step S21: initiating a public key inquiry request from a first system to a second system;
query updating step S22: the second system returns a public key inquiry response to the first system based on the public key inquiry request, and meanwhile, when the second system judges whether the current public key needs to be updated based on the public key inquiry request and returns a public key update request to the first system under the condition that the public key needs to be updated, the public key update request comprises the latest public key; and
update result notification step S23: the first system returns a second system updating result after updating the public key based on the public key updating request.
Next, a specific example will be described.
In the query request step S21, the first system initiates a public key query request to the second system, where the request carries the signature public key ID and the encryption public key ID of the second system. For example, the "public key inquiry request" is:
{“LatestSignatureKeyPairID”： “signature b1”，
LatestEncryptionKeyPairID”：“encryption b1” }。
in the query updating step S22, the second system returns a public key query response to the first system, where the response carries the signature public key ID and the encryption public key ID of the first system, and if the second system finds that the signature public key signature b1 is not the latest public key, the latest public key is returned in the response message, for example, "public key query result return, and public key update request" is:
{“LatestSignatureKeyPairID”：“signature a1”，
“LatestEncryptionKeyPairID”：“encryption a1”
“UpdatedSignatureKeyPair ID”：“signature b2”，
updatedSignature public Key ": public key value }.
In the update result notification step S23, the first system updates the public key after receiving it, and returns the result of updating the public key. For example, "public key update result notification" is:
{ “UpdatedSignatureKeyPair ID”：“signature b2”，
ResponseCode”：“Success” }。
wherein a public key inquiry request is sent from the first system to the second system according to a prescribed inquiry period. Here, the inquiry period is set to be within a period of application link probing between the two systems. If the long connection is applied for 12 hours, the period of initiation of the public key query may be 6 hours.
As one example, it is further set after the update result notification step S23 to: setting the first system and the second system within a prescribed period enables use of the latest public key or one of the current public keys. By using the double public key mechanism, both sides can support the two public and private key pairs in a period of time at the same time, and the original public and private keys cannot be removed in the system. For example, the original public-private key pair may be invalidated only when a prescribed condition is satisfied.
As one example, further including, after the update result notification step S23: and in the alarm prompting step, if the public key updating response shows that the updating is unsuccessful, the steps S21-S23 can be repeated to update again, and the old public and private keys can be used for encrypting and signing the message during the updating, if the updating is unsuccessful after the preset specified time, the system alarms, sends an alarm prompt and notifies related personnel that the updating of the key fails.
Fig. 3 is a flow chart showing a method for updating a public key between two systems according to a third embodiment of the present invention. An example of a public key preparation mechanism is shown in this third embodiment.
As shown in fig. 3, the method for updating a public key between two systems according to the third embodiment includes the following steps:
the report request step S31: initiating a public key backup request from a first system to a second system at regular time;
and a report response step S32: the second system judges whether the public key needs to be updated based on the public key backup request and returns the judging result to the first system as a backup response;
public key update request step S33: under the condition that the public key needs to be updated or the judgment result in the response is that the public key needs to be updated, the first system initiates a public key update request to the second system, wherein the public key update request contains the latest public key; and
public key update response step S34: the second system updates the current public key based on the public key update request and returns a public key update response to the first system.
Next, a specific example will be described.
In the backup request step S31, the first system initiates a public key backup request to the second system, where the request carries the latest signature public key ID and encryption public key ID of the first system. The "public key provisioning request" is, for example:
{“LatestSignatureKeyPairID”： “signature a1”， “LatestEncryptionKeyPairID”：“encryption a1” }。
in the reply step S32, the second system checks whether the latest public key stored in the system is consistent with the received reply, and the "public key inquiry reply" is embodied in the reply message, for example:
{“Need Updated”：“Yes”， }。
in the public key update request step S33, if the first system needs to update the public key itself, or it is found in the public key report that the second system requires to update the public key, a public key update request is initiated. The "public key update request" is for example:
{ "UpdatedSignatureKeyPair ID": "signature a2", updatedsignaturepublic key ": public key value }.
In the public key update response step S34, the second system responds to the update result after updating the relevant public key of the first system. For example, "public key update response" is:
{ “UpdatedSignatureKeyPair ID”：“signature a2”， “ResponseCode”：“Success” }。
the second system may also initiate a public key backup request to the first system, which is not described herein. And when the second system finds that the first system requires the public key update, the public key update can also be initiated to the first system.
The second system may also initiate a public key query request to the first system, which will not be described in detail. And when the second system finds that the public key of the first system is not the latest public key carried in the public key inquiry request, the second system can also initiate public key update to the first system.
Wherein a public key inquiry request is sent from the first system to the second system according to a prescribed inquiry period. Here, the inquiry period is set to be within a period of application link probing between the two systems. If the long connection is applied for 12 hours, the period of initiation of the public key query may be 6 hours.
As one example, after the public key update response step S34, it is further set to: setting the first system and the second system within a prescribed period enables use of the latest public key or one of the current public keys. By using the double public key mechanism, both sides can support the two public and private key pairs in a period of time at the same time, and the original public and private keys cannot be removed in the system. For example, the original public-private key pair may be invalidated only when a prescribed condition is satisfied.
As an example, after the public key update response step S34, further includes: and in the alarm prompting step, if the public key updating response shows that the updating is unsuccessful, the steps S31-S34 can be repeated to update again, and the old public and private keys can be used for encrypting and signing the message during the updating, if the updating is unsuccessful after the preset specified time, the system alarms, sends an alarm prompt and notifies related personnel that the updating of the key fails.
The present invention also provides a computer readable storage medium having a computer program stored thereon, wherein the program when executed by a processor implements the above-described method for updating a public key between two systems.
The invention also provides a computer device comprising a memory, a processor and a computer program stored in the memory and running on the processor, characterized in that the processor implements the above-mentioned method for updating the public key between the two systems when executing the program.
According to the method for updating the public key between the two systems, the update of the public key is realized by using the message interaction and processing mechanism between the systems, and when the first system (or A system) updates the public key, the second system (or B system) does not need to perform corresponding manual operation and processing. Moreover, each message does not need to carry a public key, so that the length of a normal message can be shortened, and the use efficiency of a system and a network can be improved.
Moreover, the invention also provides a public key inquiry and backup mechanism, which can realize the link application detection function without developing related messages independently. In addition, the invention uses public key inquiry and report and double public key mechanism to realize higher system fault tolerance, when one party updates public and private key pair and initiates updating public key, if the other party system does not respond to environmental problem, it does not need manual processing and intervention, and can automatically realize updating in the next inquiry and report period.
According to the method for updating the public key between the two systems, under the condition that the first system (or the A system) is interconnected with the plurality of second systems (or the B systems), the first system and each system use the same public and private key pair, and when the communication cost between the first system and each system is high, the efficiency can be obviously improved.
The above examples mainly illustrate the method of updating public keys between two systems of the present invention. Although only a few specific embodiments of the present invention have been described, those skilled in the art will appreciate that the present invention may be embodied in many other forms without departing from the spirit or scope thereof. Accordingly, the present examples and embodiments are to be considered as illustrative and not restrictive, and the invention is intended to cover various modifications and substitutions without departing from the spirit and scope of the invention as defined by the appended claims.
Claims (9)
1. The public key updating method between the two systems is characterized by comprising the following steps:
a query request step of initiating a public key query request from the first system to the second system;
a query response step, wherein the second system returns a public key query response to the first system based on the public key query request;
a public key update request step, wherein the first system judges whether the current public key needs to be updated based on the public key inquiry response and initiates a public key update request to the second system under the condition that the public key needs to be updated, wherein the public key update request contains the latest public key; and
and a public key update response step, wherein the second system updates the current public key based on the public key update request and returns a public key update response to the first system.
2. The method for updating a public key between two systems according to claim 1, wherein,
and sending a public key query request to the second system according to a specified query period from the first system.
3. The method for updating a public key between two systems according to claim 2, wherein,
the prescribed inquiry period is set in the period of application link detection between the two systems.
4. The method for updating a public key between two systems according to claim 1, wherein,
in the public key update request step, the first system initiates a public key update request to the second system based on the query response to determine whether the current public key needs to be updated or if the first system wishes to update the current public key.
5. The method for updating a public key between two systems according to claim 1, wherein,
the public key inquiry request comprises a signature public-private key pair ID and an encryption public-private key pair ID of the second system,
the public key inquiry response comprises a signature public-private key pair ID and an encryption public-private key pair ID of the first system,
the public key update request comprises a signature public-private key pair ID and a signature public key value of the latest public key.
6. The method for updating a public key between two systems according to claim 1, wherein,
the public key update response step is further followed by:
setting the first system and the second system within a prescribed period enables use of one of the latest public key or the current public key.
7. The method for updating a public key between two systems according to claim 1, wherein,
the public key update response step further comprises the following steps:
and an alarm prompting step, wherein if the public key updating response indicates that the updating is unsuccessful, an alarm prompt is sent after a preset set time.
8. A computer-readable storage medium, on which a computer program is stored, characterized in that the program, when executed by a processor, implements the method for updating a public key between two systems according to any one of claims 1 to 7.
9. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the processor implements the method of updating a public key between two systems according to any one of claims 1-7 when executing the program.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811352806.1A CN111193592B (en) | 2018-11-14 | 2018-11-14 | Public key updating method between double systems |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811352806.1A CN111193592B (en) | 2018-11-14 | 2018-11-14 | Public key updating method between double systems |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111193592A CN111193592A (en) | 2020-05-22 |
| CN111193592B true CN111193592B (en) | 2023-06-13 |
Family
ID=70707291
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811352806.1A Active CN111193592B (en) | 2018-11-14 | 2018-11-14 | Public key updating method between double systems |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111193592B (en) |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1659810B1 (en) * | 2004-11-17 | 2013-04-10 | TELEFONAKTIEBOLAGET LM ERICSSON (publ) | Updating configuration parameters in a mobile terminal |
| JP2007074164A (en) * | 2005-09-05 | 2007-03-22 | Nippon Telegr & Teleph Corp <Ntt> | System, method, and program for authentication |
| JP2008269180A (en) * | 2007-04-18 | 2008-11-06 | Hitachi Ltd | Settlement processing system, purchase history management apparatus, purchase history management method, and program |
| CN101257380A (en) * | 2007-12-05 | 2008-09-03 | 航天信息股份有限公司 | User entity for self-generating public key certificate and system and method for managing public key certificate |
| CN105262588B (en) * | 2015-11-03 | 2018-09-14 | 网易（杭州）网络有限公司 | Login method, account management server based on dynamic password and mobile terminal |
| CN108449756B (en) * | 2018-06-29 | 2020-06-05 | 北京邮电大学 | System, method and device for updating network key |
-
2018
- 2018-11-14 CN CN201811352806.1A patent/CN111193592B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN111193592A (en) | 2020-05-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10708047B2 (en) | Computer-readable recording medium storing update program and update method, and computer-readable recording medium storing management program and management method | |
| US8458455B2 (en) | Techniques for handling SSL certificate expiration and renewal | |
| CN112417379B (en) | Cluster license management method and device, authorization server and storage medium | |
| JP4993733B2 (en) | Cryptographic client device, cryptographic package distribution system, cryptographic container distribution system, and cryptographic management server device | |
| US20180183605A1 (en) | Software distribution processing device, software distribution processing method, and vehicle | |
| US20070220271A1 (en) | Online creation and delivery of cryptographically verifiable one-time password tokens | |
| US20050120203A1 (en) | Methods, systems and computer program products for automatic rekeying in an authentication environment | |
| CN103595559A (en) | System and method for transmitting big data and service system thereof | |
| CN109842506B (en) | Disaster recovery processing method, device, system and storage medium for key management system | |
| JP2022040957A (en) | Encryption key management system and encryption key controlling method | |
| CN110362984B (en) | Method and device for operating service system by multiple devices | |
| KR20240011878A (en) | Secure and reliable bridge for asset transfer between different networks with updated watcher pools | |
| KR20180027323A (en) | System and method for authenticating critical operations on solid-state drives | |
| US11695751B2 (en) | Peer-to-peer notification system | |
| CN115022101A (en) | Account data changing method and device, computer equipment and storage medium | |
| KR20150052346A (en) | Secure management and personalization of unique code signing keys | |
| US20240086562A1 (en) | User data management method and related device | |
| CN111193592B (en) | Public key updating method between double systems | |
| CN102752308A (en) | Network-based digital certificate comprehensive service providing system and implementation method thereof | |
| CN104168110A (en) | Symmetric key online updating method | |
| US11763003B2 (en) | Secure firmware interface | |
| US11509487B2 (en) | System for rollout of certificates to client and server independent of public key infrastructure | |
| KR20190078451A (en) | Server and Recovery server for performing failure recovery of service server using block chain, Method for controlling the server | |
| AU2021300461A1 (en) | Proxy method, device, and computer-readable storage medium | |
| US20230153209A1 (en) | System and method for database recovery |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |