An end-to-end secure communication encryption method and system

Abstract

The embodiment of the application discloses an end-to-end secure communication encryption method and system. The method comprises the following steps: a first service acquires a random key changing with time, creates a new encryption key in memory as an exchange key, adds the exchange key to a request message, and sends the encrypted request message to a second service at a link opposite end by using the random key; the second service acquires a random key according to a time stamp, decrypts the encrypted request message by using the random key, creates a new encryption key in memory as an exchange key, adds the exchange key to a response message, and sends the encrypted response message to the first service by using the exchange key created by the first service last time; and the first service decrypts the encrypted response message by using the exchange key created last time, and decides whether to use or clear the exchange key created by the second service last time according to whether the second service needs to be continuously requested.

Description

TECHNICAL FIELD

[0001] The embodiment of the present application relates to the technical field of secure communication, in particular to an end-to-end secure communication encryption method and system. BACKGROUND

[0002] In the prior art, whether front-end to back-end or back-end to back-end, all end-to-end encryption keys are fixed. Whether it is a symmetric encryption method or an asymmetric encryption method, if the key is stolen, the stolen key can be used to modify and re-encrypt the message, achieving the purpose of using false requests to fake real transactions. As long as the key is leaked, there is a very high risk. In order to deal with this risk, the key usually needs to be frequently replaced, resulting in a great workload for each end. SUMMARY

[0003] The embodiment of the present application provides an end-to-end secure communication encryption method and system to solve the above technical problems.

[0004] In a first aspect, the embodiment of the present application provides an end-to-end secure communication encryption method, comprising:

[0005] A first service initiates a first link request to obtain a random key that changes with time, and simultaneously creates a new encryption key in memory as its own exchange key, adds the exchange key to a request message, and uses the random key to encrypt and send the request message to a second service at the opposite end of the link;

[0006] After receiving the encrypted request message, the second service obtains the random key according to the time stamp, decrypts the encrypted request message using the random key, completes business processing, and obtains the exchange key created by the first service last time;

[0007] The second service creates a new encryption key in memory as its own exchange key, adds the own exchange key to a response message, and uses the exchange key created by the first service last time to encrypt and send the response message to the first service;

[0008] The first service uses the exchange key created by the first service last time to decrypt the encrypted response message, completes business processing, and obtains the exchange key created by the second service last time;

[0009] The first service decides whether to continue to request the second service, and uses the exchange key created by the second service last time to continue to encrypt a new request message, or clears the exchange key created by the second service last time.

[0010] In a second aspect, the embodiments of the present application provide an end-to-end secure communication encryption system, comprising: an electronic device deployed by a first service initiating a first time link request, and an electronic device deployed by a second service at a link opposite end; wherein

[0011] The first service is configured to obtain a random key changing over time, create a new encryption key in memory as its own exchange key, add the exchange key to a request message, encrypt the request message using the random key, and send the encrypted request message to the second service at the link opposite end.

[0012] The second service is configured to, after receiving the encrypted request message, obtain the random key according to a time stamp, decrypt the encrypted request message using the random key, complete service processing, and obtain the exchange key created by the first service last time; create a new encryption key in memory as its own exchange key, add the own exchange key to a response message, encrypt the response message using the exchange key created by the first service last time, and send the encrypted response message to the first service.

[0013] The first service is further configured to decrypt the encrypted response message using the exchange key created by itself last time, complete service processing, obtain the exchange key created by the second service last time, and decide whether to use or clear the exchange key created by the second service last time according to whether the second service needs to be continuously requested.

[0014] In summary, the embodiments provide an end-to-end secure communication encryption method, which can achieve the following beneficial effects:

[0015] 1. In the method of the embodiments, the key is not stored in any end, but only in the memory, and the probability of the memory being attacked and precisely locating the key is extremely low. Moreover, the key in the memory is dynamically changed, and is replaced every time the message is exchanged, which greatly reduces the risk of leakage.

[0016] 2. In the method of the embodiments, even if the key of the current link is leaked, it will be quickly perceived due to key errors on the link of one end, the illegal request link is quickly cut off, and other links are not affected.

[0017] 3. In the method of the embodiments, since the key is generated in each request link, it is not necessary to frequently replace the stored key at both ends, which reduces the burden of operation and maintenance personnel. Moreover, the key will be cleaned up in the memory after a certain period of time, and there is no risk of memory overflow. BRIEF DESCRIPTION OF DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the specific embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the specific embodiments or prior art description. Obviously, the drawings described below are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative effort based on these drawings.

[0019] Figure 1 is a flow chart of an end-to-end secure communication encryption method provided by an embodiment of the present application;

[0020] Figure 2 is a structural schematic diagram of an end-to-end secure communication encryption system provided by an embodiment of the present application. DETAILED DESCRIPTION

[0021] In order to make the objects, technical solutions and advantages of the present application clearer, the technical solutions of the present application will be described clearly and completely below. Obviously, the described embodiments are only some of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort fall within the scope of the present application.

[0022] In the description of the present application, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer" and the like indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the device or element referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as a limitation on the present application. In addition, the terms "first", "second", "third" are only for the purpose of description, and cannot be understood as indicating or implying relative importance.

[0023] In the description of the present application, it should be noted that unless otherwise explicitly specified and limited, the terms "mounting", "connecting", "connecting" should be understood broadly, for example, it can be fixedly connected, or it can be detachably connected, or integrally connected; it can be mechanically connected, or it can be electrically connected; it can be directly connected, or it can be indirectly connected through an intermediate medium; it can be the communication inside two elements. For those skilled in the art, the specific meaning of the above terms in the present application can be understood according to the specific circumstances.

[0024] Figure 1This is a flowchart of an end-to-end secure communication encryption method provided by an embodiment of the present invention. This method is applicable to an end-to-end secure communication encryption system, and is executed collaboratively by two services in the system that are to communicate. For ease of distinction and description, the initiator of the first request in the communication link is referred to as the first service, and the service at the other end of the link is referred to as the second service. The first service and the second service use a pair of identical secure hardware devices as the initial key acquisition point; this pair of devices generates the same random key that changes over time.

[0025] Based on the above premises, combined with Figure 1 The method specifically includes:

[0026] S110. The first service that initiates the first request for the link obtains a random key that changes over time, and at the same time creates a new encryption key in memory as its own exchange key, adds the exchange key to the request message, and uses the random key to encrypt the request message and send it to the second service at the other end of the link.

[0027] Specifically, assume the first service is service A and the second service is service B. Service A, as the initiator of the first request in the chain, reads a time-varying random key stored in the secure hardware device as the encryption key I0 for this request, and simultaneously creates a new encryption key in memory as the exchange key I. A1 ; and the new key I generated in memory A1 As part of the message content, the message is encrypted using the encryption key I0 read from the hardware and sent to service B.

[0028] S120. After receiving the encrypted request message, the second service obtains the random key based on the timestamp, decrypts the encrypted request message using the random key, completes the business processing, and obtains the exchange key previously created by the first service.

[0029] Specifically, after receiving the message, Service B obtains the key I0 of the hardware device for that timestamp based on the timestamp, decrypts the message, and completes the actual business processing.

[0030] Optionally, the request message carries a time stamp of the request initiation, and the security hardware devices of the first service and the second service can directly generate a random sequence corresponding to the time stamp as the initial secret key; the security hardware devices of the first service and the second service can also only include a fixed random sequence, and the first service and the second service can automatically generate the initial secret key changing with time according to the random sequence. In the second mode, the step of the first service and the second service obtaining the random initial secret key can include: the first service reads the random sequence from the security hardware device of the first service, and adds a time stamp of the request initiation converted into a certain offset to the random sequence as the random secret key changing with time; correspondingly, after receiving the encrypted request message, the second service also reads the random sequence from the security hardware device of the second service, and adds the time stamp in the request message converted into a certain offset to the random sequence to obtain the random secret key. The random sequence and the offset conversion method in the security hardware devices of the first service and the second service are the same, so that the first service and the second service can obtain the same initial secret key.

[0031] S130, the second service creates a new encryption key in the memory as its own exchange key, adds the own exchange key to the response message, and sends the response message to the first service after encrypting the response message using the exchange key created by the first service last time.

[0032] Specifically, after the service B completes the business processing, the service B uses the newly created encryption key I A1 as the return encryption key, and also creates a new encryption key I B1 as the exchange key in the memory of the service B; and the service B sends the newly created key I B1 in the memory as a content in the message to the service A, uses the encryption key I A1 in the message to encrypt the message, and returns the message to the service A.

[0033] S140, the first service uses the exchange key created by the first service last time to decrypt the encrypted response message, and completes the business processing.

[0034] Specifically, after the service A receives the response message, the service A uses the key I A1 created by the service A in the memory last time to decrypt the message, and completes the business processing, and also obtains the encryption key I B1 .

[0035] S150, the first service decides to use the exchange key created by the second service last time to continue encrypting a new request message or to clear the exchange key created by the second service last time according to whether the first service needs to continue to request the second service.

[0036] Specifically, this step includes the following two scenarios:

[0037] Scenario 1: The first service needs to continue requesting the second service. Taking services A and B as an example, in this case, service A recreates its own exchange key I in memory. A2 The exchange key I A2 Add it to the new request message and use the exchange key I created by service B last time. B1 The new request message is encrypted and sent to service B.

[0038] After receiving the new encrypted request message, service B uses its previously created exchange key I. B1 The encrypted new request message is decrypted to complete the business processing and obtain the exchange key I previously created by service A. A2 .

[0039] At the same time, service B recreates its own exchange key I in memory. B2 , and exchange their own secret key I B2 Add it to the new response message, and use the exchange key I that service A created last time. A2 The new response message is encrypted and then sent to service A.

[0040] Service A continues to cycle through the process of requesting Service B to repeat step S150, depending on whether it needs to do so again, generating message exchanges and creating a new exchange key I in each exchange. AN (The new key created for the Nth time by service A) and I BN (The new key created by service B for the Nth time), until service A no longer needs to request service B, terminating the current link.

[0041] In this way, each time the two services receive and send a message, they use the new key generated in the other party's memory to decrypt it, and provide the other party with a new key for decryption in the next time. This achieves the purpose of storing the key in memory and continuously exchanging it dynamically in each interaction.

[0042] Scenario 2: The first service does not need to request the second service. Taking services A and B as an example again, in this case, service A terminates the current link and clears the exchange keys in memory (including its own exchange key and the other party's exchange key) after a certain period of time. The next time it makes a request, it will use the first request to obtain the initial key that has changed over time from the security hardware device.

[0043] Further, the communication between services carries a timestamp, a current link ID and other key fields to mark whether the link is ended. When the first service initiates a new communication link, the request message carries a new link ID. When the second service receives a message, if the link ID in the message is inconsistent with the link ID in the previous message, it is determined that the previous link communication is ended, and the previously created exchange key is cleared. When the second service receives a message, if the current time is greatly different from the timestamp (representing the sending time of the message) in the message, it is also determined that the current link is ended.

[0044] Further, when the key is leaked (only the memory is attacked and the key is accurately located, with a very low probability), a key error occurs in any one of the two services (the key exchange is interrupted by an illegal request), so that illegal access is quickly discovered, and the opposite service is notified that the current link is unsafe. The opposite service will clear the key in the memory of the link and quickly end the illegal request link. Specifically, if illegal access occurs, the end that is illegally accessed will communicate with the illegal access, and the real opposite service will find that the exchange key created last time cannot be used to decrypt the message, indicating that the exchange key is leaked. The opposite end is notified to terminate the current link and clear the exchange key in the memory. Therefore, in the embodiment, the key is valid only in one message exchange, the leakage cost is low and can be discovered in time, and the communication security is fully guaranteed.

[0045] In summary, in the prior art, the key is stored in the end and is fixed and easy to be stolen and leaked. Once the key is leaked, it is impossible to distinguish between true and false transactions. New keys need to be frequently replaced at each end to prevent key leakage, increasing the cost of personnel frequently maintaining the keys and other defects. The embodiment provides an end-to-end secure communication encryption method, which can achieve the following beneficial effects:

[0046] 1. In the method of the embodiment, the key is not stored in any end, but only in the memory. The probability of attacking and accurately locating the key in the memory is very low, and the key in the memory is also dynamically changed every time the message is exchanged, greatly reducing the risk of leakage.

[0047] 2. In the method of the embodiment, even if the key of the current link is leaked, it can be quickly perceived due to a key error on the link of one end, the illegal request link is quickly cut off, and other links are not affected.

[0048] 3. In the method of the embodiment, since the key is generated in each request link, it is not necessary to frequently replace the stored key at both ends, reducing the burden on the operation and maintenance personnel. After a certain period of time, the key will also be cleared in the memory, and there is no risk of memory overflow.

[0049] Figure 2A structure schematic diagram of an end-to-end secure communication encryption system provided by an embodiment of the present application is shown in Figure 2 The system includes an electronic device deployed by a first service initiating a first time request of a link, and an electronic device deployed by a second service at a link opposite end. Wherein,

[0050] The first service is configured to obtain a random key changing with time, create a new encryption key in memory as its own exchange key, add the exchange key to a request message, encrypt the request message using the random key, and send the encrypted request message to the second service at the link opposite end.

[0051] The second service is configured to obtain the random key according to a time stamp after receiving the encrypted request message, decrypt the encrypted request message using the random key, complete service processing, and obtain the exchange key created by the first service last time. Meanwhile, the second service creates a new encryption key in memory as its own exchange key, adds the own exchange key to a response message, encrypts the response message using the exchange key created by the first service last time, and sends the encrypted response message to the first service.

[0052] The first service is further configured to decrypt the encrypted response message using the exchange key created by the first service last time, complete service processing, and obtain the exchange key created by the second service last time. According to whether the first service needs to continue to request the second service, the first service decides to continue to encrypt a new request message using the exchange key created by the second service last time, or to clear the exchange key created by the second service last time.

[0053] Further, if the first service needs to continue to request the second service, the first service is further configured to re-create an own exchange key in memory, add the exchange key to a request message, and encrypt the request message using the exchange key created by the second service last time and send the encrypted request message to the second service.

[0054] The second service is further configured to decrypt the encrypted request message using the exchange key created by the second service last time after receiving the encrypted request message, complete service processing, and obtain the exchange key created by the first service last time. Meanwhile, the second service re-creates an own exchange key in memory, adds the own exchange key to a response message, encrypts the response message using the exchange key created by the first service last time, and sends the encrypted response message to the first service.

[0055] The cycle continues until the first service does not need to continue to request the second service, and the current link is terminated.

[0056] If the first service does not need to continue to request the second service, the first service is further configured to terminate the current link, and clear the exchange key in the memory after a certain time length, and then reacquire the time-varying random key when initiating the request next time.

[0057] This embodiment is based on the same inventive concept as the above method embodiments, and the features of any of the above method embodiments are applicable to this embodiment and can achieve the same beneficial effects, which will not be repeated here.

[0058] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, but not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the technical solutions of the embodiments of the present application.

Claims

1. An end-to-end secure communication encryption method, characterized in that, include: The first service that initiates the first request for the link obtains a random key that changes over time, and at the same time creates a new encryption key in memory as its own exchange key. It adds the exchange key to the request message and uses the random key to encrypt the request message and send it to the second service at the other end of the link. After receiving the encrypted request message, the second service obtains the random key based on the timestamp, decrypts the encrypted request message using the random key, completes the business processing, and obtains the exchange key previously created by the first service. The second service creates a new encryption key in memory as its own exchange key, adds its own exchange key to the response message, and encrypts the response message using the exchange key previously created by the first service before sending it to the first service. The first service uses the exchange key it created last time to decrypt the encrypted response message, completes the business processing, and obtains the exchange key created by the second service last time. The first service decides, based on whether it needs to continue requesting the second service, to use the previously created exchange key to continue encrypting new request messages, or to clear the previously created exchange key. The first service and the second service use a pair of identical security hardware devices as the point of obtaining the random key, and the security hardware devices are capable of generating the same random key that changes over time; the request message carries a timestamp of the request being initiated. The first service that initiates the first request of the link obtains a random key that changes over time, including: the first service that initiates the first request of the link reads a random sequence from its own security hardware device, and adds the timestamp of the request to the random sequence as a random key that changes over time. Accordingly, after receiving the encrypted request message, the second service obtains the random key based on the timestamp, including: after receiving the encrypted request message, the second service reads a random sequence from its own security hardware device, converts the timestamp in the request message into a certain offset and adds it to the random sequence to obtain the random key; The random sequence and offset conversion method are the same in the security hardware devices of the first service and the second service. The method further includes: after the second service receives a certain message, if the link ID in the certain message is inconsistent with the link ID of the previous message, it determines that the previous link communication has ended and clears the previously created exchange key; after the first service or the second service receives a certain message, if it cannot decrypt the certain message using its previously created exchange key, it indicates that the exchange key has been leaked, and notifies the other party to terminate the current link and clear the exchange key in memory.

2. The method according to claim 1, characterized in that, The first service decides, based on whether it needs to continue requesting the second service, to either use the previously created exchange key to encrypt new request messages or to clear the previously created exchange key, including: If the first service needs to continue requesting the second service, the first service recreates its own exchange key in memory, adds the exchange key to the new request message, and uses the exchange key previously created by the second service to encrypt the new request message and send it to the second service. After receiving the encrypted new request message, the second service uses the exchange key it created last time to decrypt the encrypted new request message, completes the business processing, and obtains the exchange key created last time by the first service. The second service recreates its own exchange key in memory, adds the exchange key to the new response message, and encrypts the new response message using the exchange key previously created by the first service before sending it to the first service. This process continues until the first service no longer needs to request the second service, at which point the current connection is terminated.

3. The method according to claim 1, characterized in that, The first service decides, based on whether it needs to continue requesting the second service, to either use the previously created exchange key to encrypt new request messages or to clear the previously created exchange key, including: If the first service does not need to continue requesting the second service, the current link is terminated, and the exchanged key in memory is cleared after a certain period of time. The random key that changes over time is then obtained again when the next request is made.

4. The method according to claim 1, characterized in that, The exchange key is stored in memory for a certain period of time and then cleared, where the certain period of time is greater than the maximum time required for one message exchange.

5. An end-to-end secure communication encryption system, characterized in that, This includes: the electronic devices deployed by the first service that initiated the first link request, and the electronic devices deployed by the second service at the other end of the link; wherein, The first service is used to obtain a random key that changes over time, and at the same time create a new encryption key in memory as its own exchange key, add the exchange key to the request message, and use the random key to encrypt the request message and send it to the second service at the link peer. Upon receiving an encrypted request message, the second service retrieves the random key based on the timestamp, decrypts the encrypted request message using the random key, completes the business processing, and obtains the exchange key previously created by the first service. Simultaneously, it creates a new encryption key in memory as its own exchange key, adds its own exchange key to the response message, and encrypts the response message using the exchange key previously created by the first service before sending it to the first service. The first service is also used to decrypt the encrypted response message using the exchange key it created last time, complete the business processing, and obtain the exchange key created by the second service last time; and the first service decides, based on whether it needs to continue to request the second service, to use the exchange key created by the second service last time to continue to encrypt new request messages, or to clear the exchange key created by the second service last time. The first service and the second service use a pair of identical security hardware devices as the point of obtaining the random key, and the security hardware devices are capable of generating the same random key that changes over time; the request message carries a timestamp of the request being initiated. The first service that initiates the first request of the link obtains a random key that changes over time, including: the first service that initiates the first request of the link reads a random sequence from its own security hardware device, and adds the timestamp of the request to the random sequence as a random key that changes over time. Accordingly, after receiving the encrypted request message, the second service obtains the random key based on the timestamp, including: after receiving the encrypted request message, the second service reads a random sequence from its own security hardware device, converts the timestamp in the request message into a certain offset and adds it to the random sequence to obtain the random key; The random sequence and offset conversion method are the same in the security hardware devices of the first service and the second service. The method further includes: after the second service receives a certain message, if the link ID in the certain message is inconsistent with the link ID of the previous message, it determines that the previous link communication has ended and clears the previously created exchange key; after the first service or the second service receives a certain message, if it cannot decrypt the certain message using its previously created exchange key, it indicates that the exchange key has been leaked, and notifies the other party to terminate the current link and clear the exchange key in memory.

6. The system according to claim 5, characterized in that, The first service decides, based on whether it needs to continue requesting the second service, whether to use the previously created exchange key to encrypt new request messages or to clear the previously created exchange key: If the first service needs to continue requesting the second service, the first service recreates its own exchange key in memory, adds the exchange key to the request message, and uses the exchange key previously created by the second service to encrypt the request message and send it to the second service. After receiving the encrypted request message, the second service decrypts the encrypted request message using its previously created exchange key, completes the business processing, and obtains the exchange key previously created by the first service. At the same time, it recreates its own exchange key in memory, adds its own exchange key to the response message, and encrypts the response message using the exchange key previously created by the first service before sending it to the first service. This process continues until the first service no longer needs to request the second service, at which point the current connection is terminated.

Images