Key security management method and device, electronic equipment, medium and program product

Abstract

The application provides a key security management method and device, electronic equipment, medium and program product, relates to the technical field of computers, and the method applied to a client comprises: generating a first asymmetric key pair; signing information string agreed with a server based on a private key in the first asymmetric key pair to obtain a first signature, and sending the first signature and a public key in the first asymmetric key pair to the server, wherein the first signature is used to verify the credibility of the client; receiving first symmetric key ciphertext sent by the server, and performing decryption processing on the first symmetric key ciphertext to obtain first symmetric key plaintext; generating a first key according to the first symmetric key plaintext and a first token issued by the server for the client and pre-acquired, and performing encryption processing on first data through the first key to obtain encrypted first data, and sending the encrypted first data to the server.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, specifically to a key security management method, apparatus, electronic device, medium, and program product. Background Technology

[0002] In related technologies, the client encrypts and signs the data according to a pre-agreed data structure before transmitting the data to the server. The server verifies the signature on the encrypted data and decrypts the data to verify the structure, confirming whether the client is trusted. During this process, to prevent brute-force attacks, the client introduces anti-decompilation mechanisms to protect the rules for identification with the server. It is evident that existing key exchange and update mechanisms are complex, and key distribution and dynamic updates rely on manual intervention or fixed strategies, failing to meet real-time security requirements and easily leading to risks of key leakage or expiration. Summary of the Invention

[0003] This disclosure provides a key security management method, apparatus, electronic device, medium, and program product to solve the problem that key distribution and dynamic update processes rely on manual intervention or fixed strategies, which cannot adapt to real-time security requirements and are prone to key leakage or expiration risks.

[0004] Firstly, this application provides a key security management method applied to a client, the method comprising:

[0005] Generate the first asymmetric key pair;

[0006] Based on the private key in the first asymmetric key pair, the information string agreed upon with the server is signed to obtain a first signature, and the first signature and the public key in the first asymmetric key pair are sent to the server. The first signature is used to verify the trustworthiness of the client.

[0007] Receive the first symmetric key ciphertext sent by the server, and decrypt the first symmetric key ciphertext to obtain the first symmetric key plaintext;

[0008] Based on the plaintext of the first symmetric key and the first token issued to the client by the server in advance, a first key is generated, and the first data is encrypted using the first key to obtain encrypted first data, which is then sent to the server.

[0009] Optionally, before generating the first asymmetric key pair, the method further includes:

[0010] Send a first request to the server, the first request being used to request the server to issue the first token;

[0011] Receive the first token issued by the server.

[0012] Optionally, the step of decrypting the first symmetric key ciphertext to obtain the first symmetric key plaintext includes:

[0013] Based on the private key in the first asymmetric key pair, the ciphertext of the first symmetric key is decrypted to obtain the plaintext of the first symmetric key.

[0014] Wherein, the first symmetric key ciphertext is the ciphertext obtained by encrypting the first symmetric key based on the public key in the first asymmetric key pair, and the first symmetric key is a symmetric key randomly generated by the server.

[0015] Optionally, the method further includes:

[0016] An encryption request is sent to the server to trigger the server to verify whether the first key is valid;

[0017] Receive a first indication sent by the server, the first indication being used to indicate that the first key has expired;

[0018] Send a second request to the server, the second request being used to request the server to issue a second token;

[0019] Based on the second token and the second symmetric key issued by the server, a second key is generated. The second symmetric key is a symmetric key randomly generated by the server when the first key fails.

[0020] The second data is encrypted using the second key to obtain encrypted second data, which is then sent to the server.

[0021] Secondly, a key security management method according to an embodiment of this application is applied to a server, the method comprising:

[0022] The server receives a public key and a first signature from a first asymmetric key pair sent by the client. The first signature is a signature obtained by signing an information string based on the private key in the first asymmetric key pair. The information string is information pre-agreed between the server and the client.

[0023] If the public key in the first asymmetric key pair verifies the first signature, the first symmetric key ciphertext is sent to the client. The first symmetric key ciphertext is the ciphertext obtained by encrypting the first symmetric key with the public key in the first asymmetric key pair.

[0024] The server receives first data encrypted based on a first key sent by the client. The first key is a key generated based on the plaintext of the first symmetric key and the first token. The first token is a token pre-issued to the client by the server.

[0025] The encrypted first data is decrypted based on the first token and the first symmetric key to obtain the first data.

[0026] Optionally, before receiving the public key and the first signature from the first asymmetric key pair sent by the client, the method further includes:

[0027] Receive the first request sent by the client;

[0028] Based on the first request, the first token is sent to the client.

[0029] Optionally, sending the first symmetric key ciphertext to the client after verifying the first signature based on the public key in the first asymmetric key pair includes:

[0030] If the first signature is verified successfully based on the public key in the first asymmetric key pair, a first symmetric key is randomly generated.

[0031] The first symmetric key is encrypted using the public key in the first asymmetric key pair to obtain the ciphertext of the first symmetric key.

[0032] The first symmetric key ciphertext is sent to the client.

[0033] Optionally, the method further includes:

[0034] Receive the encryption request sent by the client, and obtain the corresponding first key based on the encryption request;

[0035] In the event that the first key has expired, a first indication is sent to the client, the first indication being used to indicate that the first key has expired;

[0036] Receive the second request sent by the client, and send a second token to the client based on the second request;

[0037] Generate a second symmetric key and send the encrypted second symmetric key ciphertext to the client;

[0038] Receive encrypted second data sent by the client;

[0039] The encrypted second data is decrypted based on the second token and the second symmetric key to obtain the second data.

[0040] Optionally, before sending a request feedback to the client in the event that the first key has expired, the method further includes at least one of the following:

[0041] The verification revealed that the key version information corresponding to the first key was an invalid version.

[0042] The timestamp corresponding to the first key was verified to indicate that the first key was not within its validity period.

[0043] The first token includes key version information corresponding to the first key and a timestamp corresponding to the first key.

[0044] Thirdly, this application also provides a key security management device for use on a client side, the device comprising:

[0045] The first generation module is used to generate the first asymmetric key pair;

[0046] The first processing module is used to sign the information string agreed upon with the server based on the private key in the first asymmetric key pair to obtain a first signature, and send the first signature and the public key in the first asymmetric key pair to the server. The first signature is used to verify the trustworthiness of the client.

[0047] The first receiving module is used to receive the first symmetric key ciphertext sent by the server and decrypt the first symmetric key ciphertext to obtain the first symmetric key plaintext.

[0048] The second processing module is configured to generate a first key based on the first symmetric key plaintext and the first token issued to the client by the server in advance, and to encrypt the first data using the first key to obtain encrypted first data, and then send the encrypted first data to the server.

[0049] Fourthly, this application also provides a key security management device applied to a server, the device comprising:

[0050] The second receiving module is used to receive the public key and the first signature from the first asymmetric key pair sent by the client. The first signature is a signature obtained by signing the information string based on the private key in the first asymmetric key pair. The information string is information pre-agreed between the server and the client.

[0051] The first sending module is configured to send a first symmetric key ciphertext to the client when the public key in the first asymmetric key pair verifies the first signature. The first symmetric key ciphertext is ciphertext obtained by encrypting the first symmetric key with the public key in the first asymmetric key pair.

[0052] The third receiving module is used to receive the first data encrypted based on the first key sent by the client. The first key is a key generated based on the plaintext of the first symmetric key and the first token. The first token is a token pre-issued to the client by the server.

[0053] The third processing module is used to decrypt the encrypted first data based on the first token and the first symmetric key to obtain the first data.

[0054] Fifthly, this application provides an electronic device including a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the method described in the first aspect, or implements the steps of the method described in the second aspect.

[0055] In a sixth aspect, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method described in the first aspect, or implements the steps of the method described in the second aspect.

[0056] In a seventh aspect, this application provides a computer program product, including computer instructions that, when executed by a processor, implement the steps of the method described in the first aspect, or implement the steps of the method described in the second aspect.

[0057] In this embodiment, the client generates a first asymmetric key pair. Based on the private key in the first asymmetric key pair, it signs the first token issued by the server to obtain a first signature. The client then sends the first signature and the public key from the first asymmetric key pair to the server to verify the client's trustworthiness. Client-driven dynamic key management generates the asymmetric key and dynamically acquires the symmetric key, reducing the complexity of key management and exchange during the identification process. Subsequently, the client receives the ciphertext of the first symmetric key sent by the server and decrypts it to obtain the plaintext of the first symmetric key, enabling automatic symmetric key upgrades without user intervention. Thus, the client can generate a first key based on the first symmetric key and the pre-issued first token, achieving one key per user and facilitating key updates. The first data is encrypted using the first key to obtain encrypted first data, which is then sent to the server. Key security management enhances the security of data transmission. Attached Figure Description

[0058] Figure 1 This is one of the flowcharts illustrating a key security management method provided in an embodiment of this application;

[0059] Figure 2 This is a second flowchart illustrating a key security management method provided in an embodiment of this application;

[0060] Figure 3 This is the third flowchart illustrating a key security management method provided in this application embodiment;

[0061] Figure 4 This is the fourth flowchart illustrating a key security management method provided in this application embodiment;

[0062] Figure 5 This is one of the structural schematic diagrams of a key security management device provided in the embodiments of this application;

[0063] Figure 6 This is a second schematic diagram of the structure of a key security management device provided in the embodiments of this application;

[0064] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0065] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0066] This application provides a key security management method, device, electronic device, medium, and program product. The following detailed description, in conjunction with the accompanying drawings, will illustrate specific embodiments and their application scenarios.

[0067] Please see Figure 1 This application provides a key security management method, which is applied to a client. The key security management method includes:

[0068] Step 101: Generate the first asymmetric key pair.

[0069] In some embodiments, the client can generate an asymmetric key pair (Rivest–Shamir–Adleman, RSA), keep the private key in the RSA locally, and send the public key in the RSA to the server in advance when obtaining the symmetric key, or it can be uploaded to the server along with the signature data.

[0070] It is worth mentioning that after the client and server complete the symmetric key exchange, they do not need to save the asymmetric key pair anymore; they can delete the private key and public key of the asymmetric key pair respectively.

[0071] Step 102: Based on the private key in the first asymmetric key pair, perform signature processing on the information string agreed upon with the server to obtain a first signature, and send the first signature and the public key in the first asymmetric key pair to the server. The first signature is used to verify the trustworthiness of the client.

[0072] In some embodiments, the client can use the private key from the generated first asymmetric key pair to perform a signing operation on the information string agreed upon with the server, generating a first signature. This first signature can serve as a credential for the server to verify the client's identity and trustworthiness. Encrypting and signing the information string with the private key ensures that the information string cannot be tampered with during transmission, preventing man-in-the-middle attacks and client forgery.

[0073] The aforementioned first signature can be a composite credential generated by the client using its private key from its own asymmetric key pair to sign a pre-agreed information string between the client and the server. Signing the encrypted information string can be used to verify the client's identity.

[0074] In this embodiment, after receiving the first signature, the server can verify and decrypt it using the public key in the first asymmetric key pair. If the verification is successful, the client is trusted (the data has not been tampered with, and the client holds the correct private key); if it fails, the process terminates (the client is untrusted).

[0075] Step 103: Receive the first symmetric key ciphertext sent by the server, and decrypt the first symmetric key ciphertext to obtain the first symmetric key plaintext.

[0076] In some embodiments, the client can release the symmetric key after the client and server stop communicating. This allows the server to assess the client's trustworthiness even when only the server retains the initial symmetric key, and the client retains no key.

[0077] Specifically, after the client sends the first signature, it can request a first symmetric key from the server. The server responds by: verifying the first signature, randomly generating a first symmetric key, and encrypting the first symmetric key using the public key from the first asymmetric key pair to generate ciphertext of the first symmetric key. The client then receives the ciphertext. The client can decrypt the ciphertext using the private key from the first asymmetric key pair to obtain the plaintext of the first symmetric key. For example, decrypting with an RSA private key yields the original plaintext of the first symmetric key. The first symmetric key is a randomly generated symmetric key by the server, used for subsequent dynamic key generation.

[0078] It's worth noting that the client can dynamically generate asymmetric key pairs using a cryptographic library. The private key of this asymmetric key pair can be stored solely on the client, while the public key can be sent to the server via a secure channel (e.g., HTTPS). Therefore, the server can store only the public key from the asymmetric key pair and use it to complete signature verification in subsequent steps.

[0079] Step 104: Based on the plaintext of the first symmetric key and the first token issued by the server to the client in advance, generate a first key, encrypt the first data using the first key to obtain encrypted first data, and send the encrypted first data to the server.

[0080] The aforementioned first token can be used for key version management. The first key can be bound to a user identity, carry key version information, and also carry key validity period information. The first token can be a unique identifier for the currently valid key version assigned by the server to the client. The key version information refers to a key version identifier, which indicates the valid key version the client should use. The server can trigger the client to update the dynamic key by updating the key version identifier in the token. Therefore, the client can trigger dynamic key updates based on updates to the key version information or validity period information in the token issued by the server, without manual intervention.

[0081] In the steps described above, the client can dynamically generate a first key (final encryption key) based on the first symmetric key and the first token according to predetermined rules. For example, the first key is generated by hashing the first symmetric key and the first token. This achieves both "one key per client" (each client's key is unique) and dynamism (the key is updated when the token is updated).

[0082] Thus, in this embodiment, the client can use a first key to encrypt first data (e.g., sensitive information requested by the user). For example, AES-GCM can be used to provide encryption and integrity, outputting "encrypted first data". After receiving the data, the server can generate a first key using the same rules (based on the stored first symmetric key and first token). If decryption is successful, the client is trusted (proving that the client holds the correct key and token); failure indicates untrustworthiness.

[0083] Therefore, the embodiments of this application are client-centric, and through simple and low-cost key management (a combination of asymmetric and symmetric keys), trusted verification is completed without user operation, which significantly improves the security of data transmission and greatly reduces encryption costs.

[0084] Optionally, before generating the first asymmetric key pair, the method further includes:

[0085] Send a first request to the server, the first request being used to request the server to issue the first token;

[0086] Receive the first token issued by the server.

[0087] In some embodiments, the first request can be automatically triggered after the user launches the client or opens an application within the client, without any user intervention. This step can occur before the client generates an asymmetric key pair, providing core input for subsequent signing and dynamic key generation.

[0088] The first request mentioned above may include a client identity identifier (such as a device identifier or application instance identifier) ​​for the server to bind the token to the client in order to achieve one password per user.

[0089] Specifically, the server can generate tokens according to predetermined rules, such as the first token being a hash of the device ID, timestamp, and server's private salt value, ensuring its uniqueness and unpredictability. Additionally, the first token can have a short validity period to prevent replay attacks. Furthermore, the server can store the mapping between the token and the client for subsequent verification.

[0090] This application embodiment introduces a short-term token issued by the server to provide a security context for the client to generate asymmetric keys, ensuring the session uniqueness of subsequent dynamic keys, and ultimately achieving zero user operation and automated security.

[0091] Optionally, the step of decrypting the first symmetric key ciphertext to obtain the first symmetric key plaintext includes:

[0092] Based on the private key in the first asymmetric key pair, the ciphertext of the first symmetric key is decrypted to obtain the plaintext of the first symmetric key.

[0093] Wherein, the first symmetric key ciphertext is the ciphertext obtained by encrypting the first symmetric key based on the public key in the first asymmetric key pair, and the first symmetric key is a symmetric key randomly generated by the server.

[0094] In some embodiments, the decryption operation is performed entirely on the client side, and the server cannot intervene (the private key does not leave the device). The server does not need to pre-allocate the first symmetric key; it dynamically generates and encrypts the first symmetric key ciphertext according to the client's request and then sends it out.

[0095] In some embodiments, the first symmetric key is one of the two inputs to the dynamically generated first key (the other input being the first token), and its confidentiality directly determines the security of the final key. Even if the first key is cracked (e.g., through memory extraction), it does not affect history or other sessions because the first symmetric key is only used for a single session.

[0096] In other embodiments, when the first key expires, the server generates a new symmetric key, encrypts it into a new symmetric key ciphertext, and sends it out. Finally, the client automatically decrypts and updates to obtain the plaintext symmetric key, without any user intervention throughout the process.

[0097] It should be noted that if an attacker intercepts the first symmetric key ciphertext, they cannot decrypt it to obtain the first symmetric key ciphertext because they lack the client's first asymmetric key, thus preventing them from forging a legitimate client. If server data is leaked, even if the server database is compromised, only the encrypted first symmetric key ciphertext can be obtained; the private key remains on the client, preventing the attacker from decrypting historical communication data. In the event of a client-side decompilation attack, the private key is stored in a hardware secure area (e.g., a Secure Enclave), making it unretrievable even if the app is reverse-engineered. In some embodiments, the first symmetric key in memory is a temporary object, destroyed immediately after use.

[0098] Thus, this embodiment of the application solves the transmission security problem of the first symmetric key by encrypting with a first asymmetric public and private key, innovating the traditional key exchange mode into a client-led on-demand request mode, reducing server management costs. It also provides a secure and controllable input for subsequently generating dynamic encryption keys for each user.

[0099] Optionally, the method further includes:

[0100] An encryption request is sent to the server to trigger the server to verify whether the first key is valid;

[0101] Receive a first indication sent by the server, the first indication being used to indicate that the first key has expired;

[0102] Send a second request to the server, the second request being used to request the server to issue a second token;

[0103] Based on the second token and the second symmetric key issued by the server, a second key is generated. The second symmetric key is a symmetric key randomly generated by the server when the first key fails.

[0104] The second data is encrypted using the second key to obtain encrypted second data, which is then sent to the server.

[0105] In some embodiments, when a client initiates an encryption request, it carries a first key. The server first needs to obtain the corresponding encryption key based on the key version, and then verify the validity of the first key. During this process, the server can confirm whether the first key is legitimate, has not been tampered with, or expired, preventing unauthorized first keys from participating in encrypted communication and avoiding information leakage or malicious tampering. Furthermore, only by verifying the validity of the first key can the server decide whether to process the request normally or issue an expiration notification, ensuring a clear and orderly encrypted interaction process and guaranteeing stable system operation.

[0106] In some embodiments, if a first instruction is received from the server, it indicates that the first key has been deemed invalid by the server, or that the first key originally had an expiration date or version number (e.g., key_version=2) that has expired, and the old version of the first key automatically becomes invalid.

[0107] The first indication mentioned above can be an API response code (e.g., HTTP 401 Unauthorized + error message {"code": "KEY_EXPIRED"}), or it can be a push notification, such as a WebSocket message. The second request can be the same as the initial token request, but must be marked as an "update request" (e.g., parameter is_renew=true). The server generates a second token, which can be a completely new random value compared to the first token and is not associated with the old token (to avoid key deduction association). Additionally, a device fingerprint can be bound to prevent token hijacking.

[0108] In some embodiments, the client re-executes the key request in the main process, sending the public key from the asymmetric key (which can be a reused public key from the old first asymmetric key or a new asymmetric key pair can be generated). The server can generate a second symmetric key (a new random value), encrypt it with the public key, and then send the second symmetric key ciphertext. The client decrypts it using its private key to obtain the original second symmetric key plaintext.

[0109] In some embodiments, the generation of the second key can use similar rules as the generation of the first key; for example, the second key = SHA256(second symmetric key + second token). The client uses the second key to encrypt current business data (e.g., a failed retry request), and the server can generate the second key using the same rules and decrypt it to complete the verification.

[0110] It's worth noting that if the first key expires, users need to log in again or manually update the app, causing a gap in the user experience. The embodiments described above implement key rotation through server failure detection, updating the first key to the second key, with data retransmission completed entirely in the background. After each key update, the old key (first key) is immediately discarded. Even if historical keys are leaked, attackers cannot decrypt new data (because the second key is generated from entirely new random numbers). Furthermore, by issuing a first instruction, the client is forced to rotate the key (e.g., when an algorithm vulnerability is discovered). The client adapts automatically, supporting the new key strategy without requiring client or app upgrades.

[0111] Therefore, in this embodiment, the client can generate a first key based on the first symmetric key and the pre-issued first token, achieving one key per user and facilitating key updates. The first data is then encrypted using the first key to obtain encrypted first data, which is finally sent to the server. This key-based security management enhances the security of data transmission.

[0112] Please see Figure 2 The second key security management method in this application specifically includes the following steps:

[0113] Step 201: When a user opens one of the applications, the client sends a first request to the server to obtain a first token;

[0114] Step 202: The server sends a first token to the client based on the first request;

[0115] Step 203: The client uses the private key in the pre-generated first asymmetric key pair to sign the information string agreed upon with the server to obtain the first signature;

[0116] Step 204: The client sends the first signature and the public key from the first asymmetric key pair to the server;

[0117] Step 205: The server verifies the first signature based on the public key in the first asymmetric key pair sent by the client;

[0118] Step 206: If the first signature verification passes, the server randomly generates a first symmetric key and encrypts the first symmetric key based on the public key in the first asymmetric key pair to obtain the first symmetric key ciphertext.

[0119] Step 207: The server sends the first symmetric key ciphertext to the client;

[0120] Step 208: The client decrypts the ciphertext of the first symmetric key based on the private key in the first asymmetric key pair to obtain the plaintext of the first symmetric key.

[0121] Step 209: The client generates a first key based on the first symmetric key and the first token, and encrypts the first data using the first key to obtain the encrypted first data;

[0122] Step 210: The client sends the encrypted first data to the server.

[0123] It is understood that all implementations of the above embodiments can be found in the foregoing. Figure 1 The relevant descriptions of the key security management method applied to the client are not repeated in this embodiment to avoid duplication.

[0124] Please see Figure 3 The third key security management method in this application specifically includes the following steps:

[0125] Step 301: When the user opens another application, the client sends an encryption request to the server;

[0126] Step 302: The server determines the first key based on the key version information in the first token;

[0127] Step 303: The server verifies whether the first key has expired;

[0128] Step 304: If the first key fails, the server sends a first indication to the client, the first indication being used to indicate that the first key has failed.

[0129] Step 305: The client sends a second request to the server, the second request being used to request to obtain a second token;

[0130] Step 306: If the first key fails, the server randomly generates a second symmetric key.

[0131] Step 307: The server sends a second token to the client based on the second request, and also sends the second symmetric key ciphertext;

[0132] Step 308: The client generates a second key based on the second token and the second symmetric key issued by the server;

[0133] Step 309: The client encrypts the second data using the second key to obtain the encrypted second data;

[0134] Step 310: The client sends the encrypted second data to the server.

[0135] It is understood that all implementations of the above embodiments can be found in the foregoing. Figure 1 or Figure 2 The relevant descriptions of the key security management method applied to the client are not repeated in this embodiment to avoid duplication.

[0136] Please see Figure 4 This application provides a key security management method applied to a server, the method comprising:

[0137] Step 401: Receive the public key and first signature from the first asymmetric key pair sent by the client. The first signature is a signature obtained by signing the information string based on the private key in the first asymmetric key pair. The information string is information pre-agreed between the server and the client.

[0138] Step 402: If the public key in the first asymmetric key pair verifies the first signature, send the first symmetric key ciphertext to the client. The first symmetric key ciphertext is the ciphertext obtained by encrypting the first symmetric key with the public key in the first asymmetric key pair.

[0139] Step 403: Receive the first data encrypted based on the first key sent by the client. The first key is a key generated based on the plaintext of the first symmetric key and the first token. The first token is a token pre-issued to the client by the server.

[0140] Step 404: Decrypt the encrypted first data based on the first token and the first symmetric key to obtain the first data.

[0141] Optionally, before receiving the public key and the first signature from the first asymmetric key pair sent by the client, the method further includes:

[0142] Receive the first request sent by the client;

[0143] Based on the first request, the first token is sent to the client.

[0144] Optionally, sending the first symmetric key ciphertext to the client after verifying the first signature based on the public key in the first asymmetric key pair includes:

[0145] If the first signature is verified successfully based on the public key in the first asymmetric key pair, a first symmetric key is randomly generated.

[0146] The first symmetric key is encrypted using the public key in the first asymmetric key pair to obtain the ciphertext of the first symmetric key.

[0147] The first symmetric key ciphertext is sent to the client.

[0148] Optionally, the method further includes:

[0149] Receive the encryption request sent by the client, and obtain the corresponding first key based on the encryption request;

[0150] In the event that the first key has expired, a first indication is sent to the client, the first indication being used to indicate that the first key has expired;

[0151] Receive the second request sent by the client, and send a second token to the client based on the second request;

[0152] Generate a second symmetric key and send the encrypted second symmetric key ciphertext to the client;

[0153] Receive encrypted second data sent by the client;

[0154] The encrypted second data is decrypted based on the second token and the second symmetric key to obtain the second data.

[0155] Optionally, before sending a request feedback to the client in the event that the first key has expired, the method further includes at least one of the following:

[0156] The verification revealed that the key version information corresponding to the first key was an invalid version.

[0157] The timestamp corresponding to the first key was verified to indicate that the first key was not within its validity period.

[0158] The first token includes key version information corresponding to the first key and a timestamp corresponding to the first key.

[0159] It should be noted that before sending the first instruction (key expiration notification), the server may perform at least one verification: verify that the key version information corresponding to the first key is an invalid version; verify that the timestamp corresponding to the first key is not within its validity period. The first token is the carrier of this determination and must contain: key version information (e.g., key_version=2) and a timestamp (e.g., expire_time=1735689600).

[0160] In some embodiments, the version validity rule may be: the server maintains a list of valid version numbers (e.g., only key_version>=3 is allowed); if the key_version in the token is not in the valid list, it is deemed invalid. For example, when forcibly upgrading the encryption algorithm (e.g., from AES-128 to AES-256), the old version key is discarded.

[0161] In other embodiments, a time window design can be implemented: a time tolerance (e.g., ±30 seconds) is introduced to handle clock discrepancies between the client and server; if current_time > expire_time + tolerance, the system is considered invalid. For example, keys can be rotated periodically (e.g., mandatory updates every 30 days) to meet financial security compliance requirements (PCI-DSS).

[0162] In other embodiments, the key version and validity period can be combined. The invalidation determination can be based on the invalid version or the expired time, or a priority can be set, with the version determination taking precedence over the time determination (for example, if the version has expired, there is no need to check the time).

[0163] Thus, this embodiment of the application can enforce key expiration through timestamps, limiting the attack window (e.g., a maximum of 30 days) even if the key is leaked. Upon discovering a vulnerability in the encryption algorithm, the server immediately marks the relevant version as invalid, and all clients automatically upgrade. This embodiment of the application can also perform pre-emptive invalidation checks, completing verification before decryption to avoid consuming CPU resources for invalid decryption.

[0164] It is understood that all implementation methods in the above embodiments can refer to the relevant descriptions in the aforementioned key security management method applied to the client. To avoid repetition, these embodiments will not be repeated here.

[0165] See Figure 5 This disclosure provides a key security management device applied to a client, such as... Figure 5 As shown, the key security management device includes:

[0166] The first generation module 501 is used to generate the first asymmetric key pair;

[0167] The first processing module 502 is used to sign the information string agreed upon with the server based on the private key in the first asymmetric key pair to obtain a first signature, and send the first signature and the public key in the first asymmetric key pair to the server. The first signature is used to verify the trustworthiness of the client.

[0168] The first receiving module 503 is used to receive the first symmetric key ciphertext sent by the server and decrypt the first symmetric key ciphertext to obtain the first symmetric key plaintext.

[0169] The second processing module 504 is configured to generate a first key based on the first symmetric key plaintext and the first token issued by the server to the client in advance, and to encrypt the first data using the first key to obtain encrypted first data, and then send the encrypted first data to the server.

[0170] Optionally, the key security management device further includes:

[0171] The second sending module is used to send a first request to the server, wherein the first request is used to request the server to issue the first token;

[0172] The fourth receiving module is used to receive the first token issued by the server.

[0173] Optionally, the first receiving module 503 is used to:

[0174] Based on the private key in the first asymmetric key pair, the ciphertext of the first symmetric key is decrypted to obtain the plaintext of the first symmetric key.

[0175] Wherein, the first symmetric key ciphertext is the ciphertext obtained by encrypting the first symmetric key based on the public key in the first asymmetric key pair, and the first symmetric key is a symmetric key randomly generated by the server.

[0176] Optionally, the key security management device further includes:

[0177] The request verification module is used to send an encryption request to the server to trigger the server to verify whether the first key is valid;

[0178] The fifth receiving module is used to receive a first indication sent by the server, the first indication being used to indicate that the first key has expired;

[0179] The third sending module is used to send a second request to the server, the second request being used to request the server to issue a second token;

[0180] The first generation module is used to generate a second key based on the second token and the second symmetric key issued by the server. The second symmetric key is a symmetric key randomly generated by the server when the first key fails.

[0181] The fourth sending module is used to encrypt the second data using the second key to obtain encrypted second data, and then send the encrypted second data to the server.

[0182] The key security management device provided in this disclosure can achieve the above-mentioned functions. Figure 1 To avoid repetition, the various processes in the illustrated key security management method embodiment will not be described again here.

[0183] See Figure 6 This disclosure also provides a key security management device applied to a server, such as... Figure 6 As shown, the key security management device includes:

[0184] The second receiving module 601 is used to receive the public key and the first signature in the first asymmetric key pair sent by the client. The first signature is a signature obtained by signing the information string based on the private key in the first asymmetric key pair. The information string is information pre-agreed between the server and the client.

[0185] The first sending module 602 is used to send a first symmetric key ciphertext to the client when the public key in the first asymmetric key pair passes the verification of the first signature. The first symmetric key ciphertext is ciphertext obtained by encrypting the first symmetric key with the public key in the first asymmetric key pair.

[0186] The third receiving module 603 is used to receive the first data encrypted based on the first key sent by the client. The first key is a key generated based on the plaintext of the first symmetric key and the first token. The first token is a token pre-issued to the client by the server.

[0187] The third processing module 604 is used to decrypt the encrypted first data based on the first token and the first symmetric key to obtain the first data.

[0188] Optionally, the key security management device further includes:

[0189] The sixth receiving module is used to receive the first request sent by the client;

[0190] The fifth sending module is used to send the first token to the client based on the first request.

[0191] Optionally, the first sending module 602 is used to:

[0192] If the first signature is verified based on the public key in the first asymmetric key pair, a first symmetric key ciphertext is randomly generated.

[0193] The first symmetric key is encrypted using the public key in the first asymmetric key pair to obtain the ciphertext of the first symmetric key.

[0194] The first symmetric key ciphertext is sent to the client.

[0195] Optionally, the key security management device is further configured to:

[0196] Receive the encryption request sent by the client, and obtain the corresponding first key based on the encryption request;

[0197] If the first key fails, a first instruction is sent to the client;

[0198] Receive the second request sent by the client, and send a second token to the client based on the second request;

[0199] Generate a second symmetric key and send the encrypted second symmetric key to the client;

[0200] Receive encrypted second data sent by the client;

[0201] The encrypted second data is decrypted based on the second token and the second symmetric key to obtain the second data.

[0202] Optionally, the key security management device further includes at least one of the following:

[0203] The first verification module is used to verify that the key version information corresponding to the first key is an invalid version.

[0204] The second verification module is used to verify that the timestamp corresponding to the first key indicates that the first key is not within its validity period.

[0205] The first token includes key version information corresponding to the first key and a timestamp corresponding to the first key.

[0206] The key security management device provided in this disclosure can achieve the above-mentioned functions. Figure 3 To avoid repetition, the various processes in the illustrated key security management method embodiment will not be described again here.

[0207] According to embodiments of this disclosure, this disclosure also provides an electronic device and a readable storage medium.

[0208] Figure 7 A schematic block diagram of an example electronic device 700 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0209] like Figure 7As shown, device 700 includes a computing unit 701, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 702 or a computer program loaded from storage unit 708 into random access memory (RAM) 703. The RAM 703 may also store various programs and data required for the operation of device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via bus 704. An input / output (I / O) interface 705 is also connected to bus 704.

[0210] Multiple components in device 700 are connected to I / O interface 705, including: input unit 706, such as keyboard, mouse, etc.; output unit 707, such as various types of monitors, speakers, etc.; storage unit 708, such as disk, optical disk, etc.; and communication unit 709, such as network card, modem, wireless transceiver, etc. Communication unit 709 allows device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0211] The computing unit 701 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above, such as key security management methods. For example, in some embodiments, the key security management method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program may be loaded and / or installed on device 700 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by the computing unit 701, one or more steps of the key security management method described above may be performed. Alternatively, in other embodiments, the computing unit 701 may be configured to perform a key security management method by any other suitable means (e.g., by means of firmware).

[0212] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0213] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0214] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0215] As used herein, the term "machine-readable medium" refers to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) used to provide machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0216] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0217] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0218] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0219] This application also provides a computer program product, including computer instructions, which, when executed by a processor, implement the above-described... Figure 1 or Figure 3The various processes of the method embodiments shown can achieve the same technical effect, and will not be described again here to avoid repetition.

[0220] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this application can be achieved, and this is not limited herein.

[0221] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A key security management method, applied to a client, characterized in that, The method includes: Generate the first asymmetric key pair; Based on the private key in the first asymmetric key pair, the information string agreed upon with the server is signed to obtain a first signature, and the first signature and the public key in the first asymmetric key pair are sent to the server. The first signature is used to verify the trustworthiness of the client. Receive the first symmetric key ciphertext sent by the server, and decrypt the first symmetric key ciphertext to obtain the first symmetric key plaintext; Based on the plaintext of the first symmetric key and the first token issued to the client by the server in advance, a first key is generated, and the first data is encrypted using the first key to obtain encrypted first data, which is then sent to the server.

2. The method according to claim 1, characterized in that, Before generating the first asymmetric key pair, the method further includes: Send a first request to the server, the first request being used to request the server to issue the first token; Receive the first token issued by the server.

3. The method according to claim 1, characterized in that, The step of decrypting the first symmetric key ciphertext to obtain the first symmetric key plaintext includes: Based on the private key in the first asymmetric key pair, the ciphertext of the first symmetric key is decrypted to obtain the plaintext of the first symmetric key. Wherein, the first symmetric key ciphertext is the ciphertext obtained by encrypting the first symmetric key based on the public key in the first asymmetric key pair, and the first symmetric key is a symmetric key randomly generated by the server.

4. The method according to claim 1, characterized in that, The method further includes: An encryption request is sent to the server to trigger the server to verify whether the first key is valid; Receive a first indication sent by the server, the first indication being used to indicate that the first key has expired; Send a second request to the server, the second request being used to request the server to issue a second token; Based on the second token and the second symmetric key issued by the server, a second key is generated. The second symmetric key is a symmetric key randomly generated by the server when the first key fails. The second data is encrypted using the second key to obtain encrypted second data, which is then sent to the server.

5. A key security management method, characterized in that, Applied to a server, the method includes: The server receives a public key and a first signature from a first asymmetric key pair sent by the client. The first signature is a signature obtained by signing an information string based on the private key in the first asymmetric key pair. The information string is information pre-agreed between the server and the client. If the public key in the first asymmetric key pair verifies the first signature, the first symmetric key ciphertext is sent to the client. The first symmetric key ciphertext is the ciphertext obtained by encrypting the first symmetric key with the public key in the first asymmetric key pair. The server receives first data encrypted based on a first key sent by the client. The first key is a key generated based on the plaintext of the first symmetric key and a first token. The first token is a token pre-issued to the client by the server. The encrypted first data is decrypted based on the first token and the first symmetric key to obtain the first data.

6. The method according to claim 5, characterized in that, Before receiving the public key and the first signature from the first asymmetric key pair sent by the client, the method further includes: Receive the first request sent by the client; Based on the first request, the first token is sent to the client.

7. The method according to claim 5, characterized in that, If the public key in the first asymmetric key pair passes the verification of the first signature, the step of sending the first symmetric key ciphertext to the client includes: If the first signature is verified successfully based on the public key in the first asymmetric key pair, a first symmetric key is randomly generated. The first symmetric key is encrypted using the public key in the first asymmetric key pair to obtain the ciphertext of the first symmetric key. The first symmetric key ciphertext is sent to the client.

8. The method according to claim 5, characterized in that, The method further includes: Receive the encryption request sent by the client, and obtain the corresponding first key based on the encryption request; In the event that the first key has expired, a first indication is sent to the client, the first indication being used to indicate that the first key has expired; Receive the second request sent by the client, and send a second token to the client based on the second request; Generate a second symmetric key and send the second symmetric key ciphertext to the client; Receive encrypted second data sent by the client; The encrypted second data is obtained by decrypting the second data based on the second token and the second symmetric key.

9. The method according to claim 8, characterized in that, Before sending a request feedback to the client in the event that the first key has expired, the method further includes at least one of the following: The verification revealed that the key version information corresponding to the first key was an invalid version. The timestamp corresponding to the first key was verified to indicate that the first key was not within its validity period. The first token includes key version information corresponding to the first key and a timestamp corresponding to the first key.

10. A key security management device, characterized in that, Applied to a client, the device includes: The first generation module is used to generate the first asymmetric key pair; The first processing module is used to sign the information string agreed upon with the server based on the private key in the first asymmetric key pair to obtain a first signature, and send the first signature and the public key in the first asymmetric key pair to the server. The first signature is used to verify the trustworthiness of the client. The first receiving module is used to receive the first symmetric key ciphertext sent by the server and decrypt the first symmetric key ciphertext to obtain the first symmetric key plaintext. The second processing module is configured to generate a first key based on the first symmetric key plaintext and the first token issued to the client by the server in advance, and to encrypt the first data using the first key to obtain encrypted first data, and then send the encrypted first data to the server.

11. A key security management device, characterized in that, Applied to a server, the device includes: The second receiving module is used to receive the public key and the first signature from the first asymmetric key pair sent by the client. The first signature is a signature obtained by signing the information string based on the private key in the first asymmetric key pair. The information string is information pre-agreed between the server and the client. The first sending module is configured to send a first symmetric key ciphertext to the client when the public key in the first asymmetric key pair verifies the first signature. The first symmetric key ciphertext is ciphertext obtained by encrypting the first symmetric key with the public key in the first asymmetric key pair. The third receiving module is used to receive the first data encrypted based on the first key sent by the client. The first key is a key generated based on the plaintext of the first symmetric key and the first token. The first token is a token pre-issued to the client by the server. The third processing module is used to decrypt the encrypted first data based on the first token and the first symmetric key to obtain the first data.

12. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the key security management method as described in any one of claims 1 to 6.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the key security management method as described in any one of claims 1 to 4, or implements the steps of the key security management method as described in any one of claims 5 to 9.

14. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the steps of the key security management method as described in any one of claims 1 to 4, or implement the steps of the key security management method as described in any one of claims 5 to 9.

Images