Communication data encryption method and device, equipment and medium

Abstract

The invention relates to the technical field of data security, can be applied to business scenes such as financial science and technology, medical health and the like, and discloses a communication data encryption method, device, equipment and medium, which comprises the following steps: generating an asymmetric key pair of a client, sending a client public key to a server, receiving a server public key and a digital signature, and after the digital signature of the server-side public key is verified, a shared symmetric encryption key is generated based on the client-side private key and the server-side public key, anti-extraction processing is performed on the shared symmetric encryption key, and the shared symmetric encryption key is stored in a client-side exclusive private directory for encrypting the communication content between the client side and the server side. According to the invention, the anti-extraction processing is carried out on the shared symmetric encryption key to ensure that the key cannot be easily extracted or cracked in the storage and use processes, so that the security of communication data encryption is enhanced, and the risk of key leakage or malicious acquisition is effectively prevented.

Description

Technical Field

[0001] The present invention relates to the field of data security technology, and in particular to a communication data encryption method, device, equipment and storage medium. Background Art

[0002] Security remains a significant challenge in mainstream mobile internet network communications. With the increasing popularity of mobile applications, various attack vectors have emerged, including algorithm cracking, protocol cracking, and man-in-the-middle attacks. These attacks make mobile application data transmission processes vulnerable to malicious interference. Especially when effective security measures are not implemented, attackers can crack encryption keys, communication protocols, or core algorithms to obtain sensitive information or control critical business logic. This not only impacts normal application use but, in severe cases, can even lead to data leakage, financial loss, and the violation of user privacy.

[0003] While symmetric encryption is widely used in current security systems due to its high encryption efficiency, satisfying the dual security and efficiency requirements between clients and servers, this approach has significant drawbacks. Symmetric encryption requires both parties to share the same key, making key security a core concern for communication security. The risk of key leakage is particularly unavoidable during key management, storage, and transmission. Consequently, traditional symmetric encryption methods often face inadequate key distribution and storage security.

[0004] In the FinTech sector, the security of encrypted communications is crucial for preventing data leaks and financial fraud. This is especially true when processing financial transaction data, personal account information, and sensitive information used in payment processes. Any form of communication theft or tampering can result in serious financial losses and legal risks. However, existing encryption technologies struggle to effectively prevent man-in-the-middle attacks, making communication security in the financial sector a significant challenge.

[0005] In the healthcare sector, with the widespread adoption of electronic health records (EHRs), telemedicine, and smart health devices, the security of medical information has become a critical issue. Medical data not only covers personal health status but may also include highly sensitive information such as drug prescriptions and medical records. Leakage of this data can cause immeasurable damage to patient privacy and the reputation of medical institutions. While existing encryption technologies can provide some degree of communication security, man-in-the-middle attacks can still lead to the leakage of patient data, potentially compromising medical decision-making and treatment outcomes.

[0006] In summary, existing technologies have obvious shortcomings in dealing with man-in-the-middle attacks and ensuring the security of encryption keys. Especially in the financial and medical fields, communication security vulnerabilities may lead to extremely serious consequences. Summary of the Invention

[0007] The main purpose of the present invention is to provide a communication data encryption method, device, equipment and storage medium, aiming to solve the technical problem that the existing technology cannot effectively prevent man-in-the-middle attacks, resulting in the security of the key negotiation process cannot be fully guaranteed.

[0008] To achieve the above object, the present invention provides a communication data encryption method, comprising:

[0009] Generate an asymmetric key pair for the client, wherein the asymmetric key pair includes a client private key and a client public key;

[0010] Send the client public key to the server, and receive the server public key and corresponding digital signature returned by the server;

[0011] Verify the digital signature of the server public key through a pre-stored trusted root certificate;

[0012] When the verification is successful, a shared symmetric encryption key is generated based on the client private key and the server public key;

[0013] Performing anti-extraction processing on the shared symmetric encryption key to generate an anti-extraction shared symmetric encryption key, and storing the key in a dedicated private directory of the client;

[0014] The communication content between the client and the server is encrypted according to the shared symmetric encryption key after the anti-extraction process.

[0015] Furthermore, to achieve the above-mentioned object, the present invention provides a communication data encryption device, comprising:

[0016] A key generation module is used to generate an asymmetric key pair for the client, wherein the asymmetric key pair includes a client private key and a client public key;

[0017] A public key exchange module, configured to send the client public key to the server and receive the server public key and corresponding digital signature returned by the server;

[0018] A digital signature verification module, used to verify the digital signature of the server public key through a pre-stored trusted root certificate;

[0019] A key negotiation module, configured to generate a shared symmetric encryption key based on the client private key and the server public key when verification is successful;

[0020] A key protection module, configured to perform anti-extraction processing on the shared symmetric encryption key, generate an anti-extraction shared symmetric encryption key, and store the key in a dedicated private directory of the client;

[0021] The encryption processing module is used to encrypt the communication content between the client and the server according to the shared symmetric encryption key after the anti-extraction processing.

[0022] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer device, which includes a memory, a processor, and a communication data encryption program stored in the memory and runnable on the processor, and when the communication data encryption program is executed by the processor, the steps of the communication data encryption method described above are implemented.

[0023] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer-readable storage medium, on which a communication data encryption program is stored. When the communication data encryption program is executed by a processor, the steps of the communication data encryption method described above are implemented.

[0024] Beneficial effects: The present invention relates to the field of data security technology and can be applied to business scenarios such as financial technology and medical health. It discloses a method for encrypting communication data, including: generating an asymmetric key pair for the client, sending the client public key to the server and receiving the server public key and digital signature, verifying the digital signature of the server public key, generating a shared symmetric encryption key based on the client private key and the server public key, performing anti-extraction processing on the shared symmetric encryption key and storing it in a client-exclusive private directory for encrypting the communication content between the client and the server. The present invention performs anti-extraction processing on the shared symmetric encryption key to ensure that the key will not be easily extracted or cracked during storage and use, thereby enhancing the security of communication data encryption and effectively preventing the risk of key leakage or malicious acquisition. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0026] Figure 1 A schematic diagram of an application environment of a communication data encryption method according to an embodiment of the present invention;

[0027] Figure 2 This is a flow chart of an embodiment of a communication data encryption method of the present invention;

[0028] Figure 3 This is a functional module diagram of a preferred embodiment of the communication data encryption device of the present invention;

[0029] Figure 4 A schematic diagram of the structure of a computer device according to an embodiment of the present invention;

[0030] Figure 5 FIG. 2 is another structural diagram of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0031] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0032] The communication data encryption method provided by the embodiment of the present invention can be applied in the following Figure 1 In an application environment, the user terminal communicates with the server terminal through a network. The server terminal can generate an asymmetric key pair for the client terminal through the user terminal, send the client public key to the server terminal and receive the server terminal public key and digital signature, verify the digital signature of the server terminal public key, and generate a shared symmetric encryption key based on the client private key and the server terminal public key, perform anti-extraction processing on the shared symmetric encryption key and store it in the client's exclusive private directory for encrypting the communication content between the client and the server terminal. The present invention performs anti-extraction processing on the shared symmetric encryption key to ensure that the key will not be easily extracted or cracked during storage and use, thereby enhancing the security of communication data encryption and effectively preventing the risk of key leakage or malicious acquisition. Among them, the user terminal can be but is not limited to various personal computers, laptops, smart phones, tablet computers and portable wearable devices. The server terminal can be implemented with an independent server or a server cluster composed of multiple servers. The present invention is described in detail below through specific embodiments.

[0033] See also Figure 2 , Figure 2 This is a flow chart of an embodiment of the communication data encryption method provided by the present invention. It should be noted that although a logical order is shown in the flow chart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0034] like Figure 2 As shown, the communication data encryption method proposed by the present invention includes the following steps:

[0035] S10, generating an asymmetric key pair for the client, wherein the asymmetric key pair includes a client private key and a client public key;

[0036] In this embodiment, in the communication data encryption method, generating an asymmetric key pair for the client is one of the fundamental operations for achieving secure communication. This asymmetric key pair consists of a client private key and a client public key. Asymmetric encryption algorithms rely on the pairing of public and private keys and play a key role in key negotiation and data encryption. The client private key is used to decrypt data encrypted by its public key or to perform digital signatures, while the client public key is widely used to encrypt data or verify signatures. The private key can only be owned by the client, while the public key can be made public, ensuring security and trustworthiness when both parties perform identity authentication and data encryption during communication.

[0037] The process of generating a client asymmetric key pair primarily involves generating a client private key and a client public key. When generating the private key, the system uses a random number generator to generate an unpredictable private key from a large range, which serves as the basis for subsequent encryption and decryption operations. The client then uses the private key to generate a public key, which is the client's public key and can be used for encryption or signature verification. This process is typically accomplished using an encryption algorithm such as elliptic curve cryptography (ECC) or RSA. ECC, due to its small key length and efficient encryption and decryption speed, is widely used in environments requiring efficient encryption, such as mobile devices.

[0038] When generating an asymmetric key pair on the client, the first step is to select an encryption algorithm. For example, ECC (Elliptic Curve Cryptography) has a smaller key size and, compared to RSA, provides more efficient computing performance at the same security level. Therefore, ECC is generally more suitable for use in resource-constrained environments such as mobile and embedded devices. The key generation process typically relies on a high-quality random number generator, which uses hardware support provided by the operating system or a dedicated hardware security module (HSM) to generate the private key. The generated private key must be kept confidential and stored only on the client device; the public key, on the other hand, can be disclosed during communication, allowing other parties to use the public key for encrypted communication or authentication with the client.

[0039] The generated key pair (private and public keys) is typically stored in a secure area of ​​the device, such as a hardware security module (HSM) or a trusted execution environment (TEE), to prevent the private key from being leaked or exposed to malware. The client's private key is only used to decrypt information or sign, while the public key is used to encrypt information or verify signatures.

[0040] For example, in the financial sector, when a customer transfers funds through a mobile app, an asymmetric key pair is generated to encrypt the customer's transaction data and authenticate their identity. The client's public key is used to encrypt the transaction request, and the server uses the client's private key to decrypt the transaction content, ensuring that only the client can sign or decrypt the transaction content. This process protects financial data and prevents man-in-the-middle attacks and data leaks.

[0041] In the healthcare sector, patient medical data is transmitted using encryption, ensuring that sensitive data, such as patient medical records, is protected during transmission. Client-generated asymmetric key pairs enable healthcare institutions to process and verify patient records in a secure environment, preventing unauthorized access or tampering.

[0042] By generating asymmetric key pairs for the client, the system ensures the security of data encryption and authentication. The client's private key is held solely by the client and remains private, preventing the risk of man-in-the-middle attacks and data tampering. Simultaneously, the public key can be publicly disseminated, ensuring the trustworthiness of encrypted communications between the client and server using the public-private key pairing. This process significantly enhances data transmission security and effectively mitigates potential risks associated with key leaks.

[0043] S20, sending the client public key to the server, and receiving the server public key and corresponding digital signature returned by the server;

[0044] In this embodiment, the client public key is used to encrypt data or verify signatures, while the server public key is typically used for authentication during encrypted data transmission. To ensure the trustworthiness of both communicating parties, the public key returned by the server is digitally signed. This process ensures the authenticity and integrity of the server public key through verification of a digital certificate and a trusted root certificate.

[0045] The client first generates an asymmetric key pair (private and public keys). The client's public key is used to encrypt data or verify signatures during communication. The client then sends the generated public key to the server via an encrypted protocol. The client's public key should be protected during transmission using an encrypted protocol to ensure that it cannot be tampered with or intercepted. In practice, the client's public key is transmitted between the client and server using an encrypted protocol (such as TLS / SSL). The client then sends the public key to the server via a secure communication channel (such as HTTPS).

[0046] After receiving the client's public key, the server generates an asymmetric key pair and makes its public key public (exchanging public keys with the client). To ensure the authenticity of the server's public key during communication, the server digitally signs the public key using its private key. The digital signature ensures the integrity of the server's public key, preventing tampering during transmission. The server returns the signed public key and the signature to the client. The returned information includes the server's public key and the digital signature generated using the server's private key. The digital signature, generated using a cryptographic algorithm, proves that the public key was indeed generated by the server, ensuring that the client can verify the server's identity during communication.

[0047] After receiving the server's public key and its digital signature, the client verifies the signature using a trusted root certificate. The root certificate ensures that the signature was issued by a trusted Certificate Authority (CA), thereby confirming the authenticity of the server's public key. Only after successfully verifying the signature will the client use the server's public key for encryption, eliminating the risk of man-in-the-middle attacks.

[0048] By sending the client's public key to the server and receiving the server's public key and digital signature, both parties can be authenticated, avoiding the risks of man-in-the-middle attacks and server identity forgery. The client can verify the legitimacy of the server's public key, ensuring encryption security during data transmission and preventing data leakage or tampering. The use of digital signatures enhances the credibility of the server's identity and effectively improves system security.

[0049] S30, verifying the digital signature of the server public key through a pre-stored trusted root certificate;

[0050] In this embodiment, to prevent man-in-the-middle attacks and public key tampering or forgery, the authenticity of the server's public key must be ensured through a digital signature. Digital signature verification typically relies on a pre-stored root certificate. A root certificate is issued by a trusted certificate authority (CA) and contains the authority's public key. The client can use this public key to verify the signature of the server's public key, thereby ensuring the security and integrity of communications.

[0051] When a client is used for the first time, the system pre-stores a trusted root certificate. This root certificate is issued by a trusted certificate authority (CA) and is typically stored in the operating system's trust store or the application's trust certificate library. The root certificate contains the CA's public key, which is used to verify all certificates issued by that CA.

[0052] When the client establishes a connection with the server, it receives the server's public key and a digital signature generated using the server's private key. The digital signature is generated by encrypting the server's public key with a specific message digest (such as the public key), ensuring that the public key has not been tampered with.

[0053] The client uses the locally stored root certificate to verify the digital signature of the server's public key. Specifically, the client uses the public key in the root certificate to decrypt the digest value generated by the server's digital signature and then compares the decrypted result with the digest calculated using the server's public key. If they match, it indicates that the server's public key was indeed signed by a trusted CA and has not been tampered with during transmission.

[0054] The client decrypts the digital signature of the server's public key using the CA public key in the root certificate. If the digital signature verification succeeds, the client confirms that the received server public key is legitimate and has not been tampered with. If verification fails, the client refuses to continue communication and can trigger an early warning mechanism to ensure that subsequent communications are not compromised.

[0055] In practice, the client first loads the root certificate from the operating system or application's trust store. After receiving the public key and digital signature from the server, the client decrypts and compares the public key in the root certificate with the digital signature of the server's public key. This process requires encryption and certificate verification mechanisms, such as those in the TLS / SSL protocol, to ensure transmission security. During this process, any unauthorized or tampered server public key will be rejected, and the communication connection will be terminated to prevent data leakage or tampering.

[0056] By verifying the digital signature of the server's public key, the client can ensure the authenticity of the server's identity, preventing man-in-the-middle attacks and the risk of server public key tampering. The use of a root certificate strengthens the credibility of the server's identity, ensuring the security of the public key during communication, and thus protecting the integrity and privacy of data transmission.

[0057] S40, when the verification is successful, generating a shared symmetric encryption key based on the client private key and the server public key;

[0058] In this embodiment, the shared key is typically generated through a key agreement protocol (such as ECDH). This process uses the client's private key and the server's public key to generate a shared key based on the server's identity verification, ensuring that the encryption key used during communication is jointly owned by both parties and cannot be stolen or tampered with by a middleman.

[0059] The client's private key is private information securely stored by the client device during the key generation process. The server's public key is a key disclosed to the client by the server through a digital certificate or public key infrastructure (PKI). During key negotiation, the client combines its private key with the server's public key to generate a shared encryption key using an algorithm.

[0060] The Elliptic Curve Diffie-Hellman (ECDH) algorithm is a commonly used key agreement algorithm. It uses elliptic curve mathematical operations to calculate the same shared symmetric encryption key from the client's private key and the server's public key. The advantage of the ECDH algorithm is that even when the public key is transmitted during communication, the private key is never exposed, thus ensuring key security. The client uses its own private key and the public key provided by the server through elliptic curve operations to generate a shared key. This key is the symmetric encryption key used for subsequent encrypted communications.

[0061] The generated shared symmetric encryption key is used to encrypt and decrypt subsequent communication data. Symmetric encryption keys use the same key for both encryption and decryption, so maintaining consistency between the communicating parties is crucial. Once generated, the key is used only for that session and cannot be disclosed.

[0062] Once the server's public key's digital signature has been verified, the client can securely generate a shared key. This is because the server's identity has been verified and the public key has not been tampered with, ensuring the validity and security of the generated shared key.

[0063] The shared key generated by this method can only be calculated by the client and the server. No middleman can interfere with or obtain the key without knowing the private key, thus effectively avoiding the risk of man-in-the-middle attacks.

[0064] For example, in the financial sector, when a user transfers funds between a banking app and a bank server, the client uses the bank's public key and its own private key to generate a shared symmetric encryption key. This key is used to encrypt the transmitted financial data, ensuring that the user's account information and transaction data are not tampered with or leaked during the transfer. The client verifies the digital signature of the server's public key to ensure that the communicating party is indeed the bank server, thus preventing hackers from posing as the bank server and stealing data.

[0065] In the healthcare sector, health data exchanged between patients and medical institutions requires encrypted transmission. By generating a shared symmetric encryption key using the client's private key and the medical institution's public key, patients' health information remains encrypted during transmission, preventing data theft. This key negotiation method ensures the security and privacy of medical data, while also ensuring that patients' data is transmitted only between authorized medical institutions.

[0066] By generating a shared symmetric encryption key using the client's private key and the server's public key, key security is ensured during encrypted communication. This method eliminates the risk of private key leakage, and the key agreement algorithm ensures that the keys generated by both parties are unique and consistent. The client and server can securely and reliably generate a shared key, ensuring data confidentiality and integrity while mitigating the risk of man-in-the-middle attacks.

[0067] S50, performing anti-extraction processing on the shared symmetric encryption key, generating a shared symmetric encryption key after the anti-extraction processing, and storing the key in a dedicated private directory of the client;

[0068] In this embodiment, to prevent the key from being extracted or cracked on the device, it must be subjected to "anti-extraction processing." This processing increases the difficulty for attackers to extract the key by cryptographically transforming it (such as shifting, obfuscating, splitting, etc.). It also ensures that even if the key is leaked, attackers cannot easily restore the original key, thereby enhancing system security.

[0069] The goal of anti-extraction processing is to ensure that even if an attacker gains access to client storage, the obtained key cannot be used directly. This typically involves transforming the key to remove its original structural characteristics. Only the correct algorithm and the necessary key information can restore it to a valid encryption key. This process prevents malicious software from extracting the key from the device's storage media. Because the key processing involves the use of unique device identification and session information, even if an attacker possesses the key data, they cannot reconstruct the original key.

[0070] For example, in the first step of the anti-extraction process, a "circular shift" operation is performed on the byte sequence of the shared symmetric encryption key. This operation shifts the key bytes according to certain rules (such as offset and direction), changing the byte order of the key. The shifted key loses its original structural characteristics, increasing the difficulty of extracting information from the key data. Specifically, the shift strategy can be determined based on the device's unique identifier so that the key transformation operation on each device is unique, thereby avoiding the security risks caused by multiple devices sharing the same key.

[0071] The shifted key byte sequence cannot be directly stored as the final key, so it is then "obfuscated." This obfuscation process involves applying a "confusion factor," a random factor generated based on the device's unique identifier and session identifier, to the shifted key byte sequence, performing a bit-level operation. This operation further scrambles the original key data, making it difficult for an attacker to recover the original shared secret even if they obtain the shifted key.

[0072] After the key is shifted and obfuscated, the resulting "shared symmetric encryption key" is stored in the client's dedicated private directory. This dedicated private directory provides an isolated storage space for client applications, where key data is protected from external access. Keys are further encrypted during storage for added security. Each key read requires validation to ensure the key has not been tampered with.

[0073] During storage, in addition to preventing key extraction, the key itself is encrypted before storage to prevent it from being unreadable even if an attacker accesses the private directory. Typically, keys are encrypted using a symmetric encryption algorithm and combined with the device's cryptographic hardware (such as a security chip) for storage and retrieval operations, further ensuring key security.

[0074] Furthermore, anti-extraction processing is a technical means of protecting sensitive data, particularly encryption keys. Its primary goal is to prevent the unauthorized extraction or misuse of keys during storage or transmission. In addition to increasing the difficulty of key extraction through shifting and obfuscation, several other effective anti-extraction methods exist. These methods can be combined to form multiple layers of protection, further enhancing security.

[0075] One method of preventing extraction is through key splitting. In this method, the key is divided into multiple parts, each stored in a different storage location or device. Even if an attacker obtains a portion of the key, they cannot recover the entire key from a single part. Key splitting not only increases the difficulty of extraction but also ensures that even if part of the data is leaked, the attacker cannot recover the encrypted content. This method is often used in conjunction with cryptographic hardware, using a hardware security module (HSM) to store the key shards, further enhancing security.

[0076] Another effective anti-extraction method is dynamic key generation and regular key updates. By regularly generating and updating new keys, attackers cannot obtain persistent keys through long-term storage and cracking. Dynamic key generation is often combined with session management mechanisms to generate new keys for each session or request. This not only avoids the risk of long-term key exposure but also reduces the risk of large-scale data breaches caused by key compromise.

[0077] In addition, hardware encryption can also be used as a method to prevent extraction. Hardware encryption typically uses specialized hardware devices to store and protect keys, such as secure encryption chips and TPM (Trusted Platform Module) hardware. Hardware encryption ensures that keys are not stored as plaintext in device memory. Instead, they are encrypted at the hardware level, making it impossible to extract keys even if the device is physically accessed. Hardware encryption, combined with other technologies such as key generation, storage, and verification operations, can provide a higher level of security for encrypted communications.

[0078] Finally, key access control and auditing are also important means of preventing key extraction. Strict access control policies ensure that only authorized applications or users can access keys. Combined with audit logs, key usage can be recorded and analyzed in detail. Once abnormal or unauthorized access is discovered, timely measures can be taken to prevent key misuse. This approach is particularly suitable for scenarios with high security requirements, such as financial institutions and medical data systems.

[0079] In summary, anti-extraction methods are not limited to shifting and obfuscation. Key splitting, dynamic updates, hardware encryption, and strict access control can all be combined with traditional anti-extraction methods to form a multi-layered defense mechanism. This combination of methods can provide comprehensive security for encryption systems, preventing attackers from obtaining and misusing keys through various means.

[0080] By implementing anti-extraction processing on shared symmetric encryption keys, the generated key data cannot be easily extracted. Even if the device is attacked or the key storage directory is accessed, the key cannot be recovered. This effectively improves data security during communication, reduces the risk of key theft and misuse, and strengthens the security of encrypted communications between clients and servers, preventing potential attackers from obtaining sensitive information by cracking the key.

[0081] S60: Encrypt the communication content between the client and the server according to the shared symmetric encryption key after the anti-extraction process.

[0082] In this embodiment, the anti-extraction processing increases the security of the key so that even if an attacker obtains partial information, it is still difficult to extract the complete key. Therefore, a processed and more secure shared symmetric encryption key is used in encrypted communication.

[0083] Retrieval-resistant shared symmetric encryption keys are keys that have undergone multiple layers of protection, including shifting, obfuscation, and key splitting. These techniques aim to minimize key extraction, even in less secure environments. This enhances key security, preventing key extraction through direct access to storage or memory.

[0084] The process of encrypting communications using a shared, symmetric encryption key that has been protected against extraction typically employs a symmetric encryption algorithm, such as AES (Advanced Encryption Standard) or other modern encryption algorithms. Symmetric encryption algorithms utilize the same key for both encryption and decryption, making them fast and suitable for large-scale data encryption. During the encryption process, the client encrypts the data using the protected, shared symmetric encryption key, ensuring that the data is encrypted before transmission and can only be decrypted by the server, which possesses the same key. The confidentiality of the encryption key is crucial during this process, and therefore relies on the key protection mechanisms implemented in the previous protection against extraction.

[0085] The encryption method can be block-based (such as AES) or stream cipher (such as RC4). During encryption, the communication content is converted into encrypted data according to a specific algorithm and pattern and transmitted to the server. Both the client and the server must use the same shared symmetric encryption key, which has been processed to prevent extraction, for encryption and decryption to ensure data confidentiality and integrity.

[0086] Key management is equally important when it comes to encryption. Shared symmetric encryption keys, after being processed to prevent extraction, must be strictly managed and accessible only to authorized applications and users. Furthermore, keys must be protected during transmission using secure protocols (such as TLS) to prevent interception or leakage during transmission.

[0087] Data encryption not only protects the confidentiality of data but also prevents data from being tampered with during transmission. Even if an attacker intercepts the encrypted data, they cannot restore the original data without the key, making it impossible to access or tamper with it.

[0088] By encrypting client-server communications using a shared symmetric encryption key that has been protected from extraction, the security of the communication data can be significantly improved. This protection ensures that even if an attacker obtains the key while it is stored, the original key cannot be easily recovered, thereby enhancing the confidentiality and integrity of the entire communication process. Furthermore, the use of a symmetric encryption algorithm increases encryption speed and ensures efficient data protection, meeting the needs of large-scale communication scenarios.

[0089] Example: In financial transactions, ensuring user identity verification and data confidentiality is crucial. Traditional cryptographic methods, such as symmetric or public key encryption, often face the risks of key leakage and man-in-the-middle attacks. To enhance communication security, a shared symmetric encryption key is generated based on the client's private key and the server's public key, and key security is ensured through anti-extraction processing. In actual implementation, when a client conducts an online transaction, the client first generates an asymmetric key pair consisting of a private key and a public key. The client's public key is sent to the server via an encryption protocol, and the server responds with its public key along with a digital signature. The client verifies the digital signature of the server's public key using a pre-stored trusted root certificate to ensure it originates from the legitimate server. Once verification is successful, the client and server use their respective keys to negotiate a shared symmetric encryption key, generating the key used to encrypt subsequent transaction data. To prevent malicious attackers from stealing the key through man-in-the-middle attacks, this solution employs anti-extraction processing. By performing cyclic shifts and obfuscation on the shared symmetric encryption key, even if an attacker obtains the key, they cannot decrypt the communication content. Furthermore, all critical data used in the key generation process (such as elliptic curve algorithm parameters, device identifiers, and session identifiers) is encrypted and stored to prevent malicious tampering or leakage. During a transaction, if any anomalies are detected in the client device or network environment, the client automatically discards the current key and prohibits reconnecting to the server during a cooldown period. This prevents attackers from easily restoring the communication connection even after an attack, effectively ensuring transaction security.

[0090] In the healthcare sector, the protection of patients' medical and personal information is extremely demanding. Hospitals and healthcare providers must ensure the confidentiality, integrity, and validity of patient data, while also protecting it from third-party access and tampering during transmission. When a patient authenticates within a healthcare provider's application, the client generates an asymmetric key pair consisting of a private key and a public key. The client's public key is sent to the server, which returns its public key with a digital signature. The client verifies the server's public key using a pre-existing trusted root certificate to confirm its legitimacy. Once verification is successful, the client and server use the elliptic curve key exchange protocol to generate a shared symmetric encryption key, which is used to protect the patient's medical data. To further ensure security, the generated shared symmetric encryption key is protected against extraction. Specifically, the client cyclically shifts and obfuscates the shared symmetric encryption key using the device and session identifiers, ensuring its uniqueness and security. This ensures that even if an attacker obtains the encrypted data, they cannot decrypt the key and access the patient's sensitive information. Furthermore, the system strictly manages the key lifecycle. Keys are periodically renegotiated, and if the client detects a device reboot or environmental security risk, the current key is discarded and a new key is generated. All key generation processes and related parameters (such as device ID and session ID) are encrypted and stored in the client's dedicated private directory to prevent unauthorized access.

[0091] The present invention relates to the field of data security technology and can be applied to business scenarios such as financial technology and medical health. A communication data encryption method is disclosed, including: generating an asymmetric key pair for a client, sending the client public key to a server and receiving the server public key and digital signature, verifying the digital signature of the server public key, generating a shared symmetric encryption key based on the client private key and the server public key, performing anti-extraction processing on the shared symmetric encryption key and storing it in a client-exclusive private directory for encrypting the communication content between the client and the server. The present invention performs anti-extraction processing on the shared symmetric encryption key to ensure that the key will not be easily extracted or cracked during storage and use, thereby enhancing the security of communication data encryption and effectively preventing the risk of key leakage or malicious acquisition.

[0092] In one embodiment, the above step S50 includes:

[0093] S501, performing a cyclic shift process on the byte sequence of the shared symmetric encryption key to generate a cyclically shifted shared symmetric encryption key;

[0094] S502, generating an obfuscation factor based on the device identifier of the client, performing obfuscation processing on the shared symmetric encryption key after the cyclic shift processing based on the obfuscation factor, and generating the shared symmetric encryption key after the obfuscation processing as the shared symmetric encryption key after the anti-extraction processing;

[0095] S503, dividing the shared symmetric encryption key after the anti-extraction processing into multiple key data blocks, and adding padding bytes to each key data block to match a preset storage length;

[0096] S504: Store the multiple key data blocks in multiple scattered sub-paths of the client's exclusive private directory respectively, and generate an anti-tampering check code for each key data block.

[0097] In this embodiment, the purpose of the anti-extraction process is to enhance the security of shared symmetric encryption keys, ensuring that even if an attacker obtains the key, it cannot be effectively exploited. This process performs a series of processing on the key to make it more difficult to extract and exploit through reverse engineering, physical attacks, or memory leaks.

[0098] In the first step of the anti-extraction process, the client performs a circular shift on the byte sequence of the shared symmetric encryption key. The purpose of the shift operation is to increase the key's complexity by changing its order, making it difficult to guess or crack. A circular shift involves shifting the key's bits in a circular pattern, either left or right. In practice, the shift amplitude (offset) is predefined and can be set based on a random number or a fixed rule, ensuring that a different key pattern is generated each time the key is processed.

[0099] To further enhance key security, after the cyclic shift process, the client generates a confusion factor based on the device identifier. The device identifier is unique, and each client device has its own identifier, making the generated confusion factor closely tied to the device. By using the device identifier as a seed and entering it into a predefined algorithm, the client generates a unique confusion factor. The confusion factor further scrambles the key, increasing its unpredictability and preventing attackers from reversing the known key pattern.

[0100] The client performs an exclusive-OR (XOR) operation on the generated obfuscation factor and the cyclically shifted shared symmetric encryption key to generate the obfuscated shared symmetric encryption key. XOR is an encryption technique in which each bit is compared with the input value to determine the result. The addition of the obfuscation factor changes the key structure, making it impossible for an attacker to directly deduce the complete key, even if they obtain a partial key, thus enhancing the key's resistance to cracking.

[0101] To facilitate storage and management, the client splits the shared symmetric encryption key, after extraction protection, into multiple key data blocks. This splitting operation breaks the long key into smaller components that can be stored and managed independently. During this step, the client also appends padding bytes to each data block to ensure that the storage length of each data block meets the preset storage requirements. This padding is intended to maintain the integrity of the key data block and prevent errors caused by insufficient key length or data misalignment.

[0102] Finally, the client stores all key data blocks in different sub-paths of a dedicated private directory to achieve decentralized storage. This decentralized storage method greatly improves the security of the key because even if a storage location is accessed by an attacker, the other key data blocks remain secure. In addition, to prevent the key data blocks from being tampered with during storage, each data block is attached with an anti-tampering checksum. The checksum is usually generated using a cryptographic hash algorithm (such as SHA-256) and is used to verify the integrity of the key data block, ensuring that the key data has not been tampered with during storage or transmission.

[0103] During implementation, the client first splits the shared symmetric encryption key after anti-extraction processing into multiple key data blocks according to the encryption standard. These data blocks are stored encrypted, and appropriate padding bytes are selected based on the characteristics of each data block to ensure that its length is suitable for storage requirements. Each key data block is attached with a generated checksum and stored in the client's private directory, which can be additionally encrypted and protected. The client ensures the security of each storage location through a proprietary storage mechanism and uses multiple security strategies (such as file system-level encryption and path access control) to protect these storage locations from unauthorized access.

[0104] This embodiment effectively enhances key security by segmenting and distributing the shared symmetric encryption key after anti-extraction processing, and generating a tamper-proof checksum for each data block. Even if an attacker successfully accesses a portion of the storage path, they cannot reconstruct the complete key by obtaining a portion of the data block. This distributed storage approach increases key protection, while the tamper-proof checksum ensures the integrity of the key data block during storage and transmission, effectively preventing data tampering and loss.

[0105] In one embodiment, the above step S501 includes:

[0106] S5011, performing a cyclic shift operation on each byte of the shared symmetric encryption key according to a preset shift strategy to generate an initially shifted shared symmetric encryption key;

[0107] S5012, performing an XOR operation on the byte sequence of the initially shifted shared symmetric encryption key and the device identifier of the client to generate an intermediate shifted shared symmetric encryption key;

[0108] S5013, inserting random padding bytes into the byte sequence of the shared symmetric encryption key after the intermediate shift to maintain the original key length, and generating a padded shared symmetric encryption key;

[0109] S5014: Use the padded shared symmetric encryption key as the shared symmetric encryption key after cyclic shift processing, and encrypt and store the preset shift strategy and the position information of the random padded bytes in the client's exclusive private directory.

[0110] In this embodiment, a cyclic shift process is used to further enhance the security of the shared symmetric encryption key, ensuring that the key is difficult to crack during storage and transmission. The main purpose of this process is to change the structure of the key so that it no longer has any directly recognizable pattern, thereby increasing the computational complexity required to crack the key.

[0111] First, the client performs a circular shift on each byte of the shared symmetric encryption key according to a preset shift strategy. This operation shifts each byte in the key by a defined offset and rotation direction, generating the initial shifted shared symmetric encryption key. The core of the shift strategy lies in the "offset" defining the amount of shift for each byte, while the "rotation direction" determines the direction of the shift (e.g., left or right). This shift operation disrupts the original structure of the key, making it difficult for attackers to crack the key through conventional pattern recognition.

[0112] Offset and rotation direction are critical parameters in key encryption. Their selection directly impacts encryption strength and key security. These are typically determined based on specific algorithmic rules or predefined policies. Different implementations can select appropriate offset and rotation directions based on encryption requirements.

[0113] The offset typically refers to the number of steps by which each byte is shifted during a circular shift operation. One way to determine the offset is based on the key length, a pre-defined security standard, or a dynamic factor (such as a timestamp, session identifier, or device identifier). In some implementations, the offset can be a fixed value, for example, all bytes are shifted in steps of 64, 128, or 256 bits. This approach is simple and computationally efficient, but it is also relatively easy to crack because knowing the fixed offset makes it relatively easy to crack. Another implementation uses a dynamic offset. This can be achieved by using certain uncertain parameters (such as a unique device identifier, timestamp, or session identifier) ​​as input and combining them with a hash function or pseudo-random number generator (PRNG) to generate the offset. For example, the client device identifier can be concatenated with the current timestamp, and a hash value generated using a hash algorithm (such as SHA-256) can be used to generate the hash value. The low-order bits of this hash value can then be used as the offset. This approach improves the security of key cryptography because even if an attacker obtains certain keys and data, the specific value of the offset is difficult to predict.

[0114] The rotation direction determines whether the key bits are shifted left or right during the shift. The rotation direction can be based on a static preset value or dynamically adjusted based on different implementation requirements. One approach is to preset a fixed rotation direction. For example, you can choose to shift left or right by a fixed number of steps. In this case, all bytes are shifted in the same direction. This approach is simple to implement, but it can be easily cracked when security requirements are high. To address this issue, dynamic rotation direction can be used.

[0115] Dynamic rotation direction is typically tied to the specific context of key generation or to external factors such as device identifiers, system configuration, or session parameters. For example, a random number can be generated based on the client's device identifier (such as the IMEI number or UUID), and the direction of the shift is determined based on this random number. If the generated random number is odd, the shift is performed to the left; if it is even, the shift is performed to the right. In this way, each generated key will have a different rotation direction on different devices, making it more difficult to crack.

[0116] Furthermore, complex algorithms can be used to dynamically adjust the loop direction based on other encryption algorithm parameters. For example, during encryption, the loop direction can be dynamically adjusted based on packet size or session status to adapt to varying network environments or computing requirements. This approach has the advantage of making the key encryption process more flexible and unpredictable, further increasing the difficulty of cracking.

[0117] After generating the initial shifted shared symmetric encryption key, the client performs an XOR operation on the key's byte sequence with the client's device ID. This XOR operation compares the client's device ID with the shifted key bit by bit to generate an intermediate shifted shared symmetric encryption key. This XOR operation strengthens the correlation between the key and the device ID, further preventing cross-device key leakage. If an attacker obtains the key data of one device, they cannot use this data to deduce the key on other devices.

[0118] Next, the client inserts random padding bytes into the shifted shared symmetric encryption key byte sequence. This padding operation maintains the original key length and ensures that each data block is stored consistently. Padding bytes are typically randomly generated to increase the complexity of key cracking. This padded key not only ensures consistent key length but also increases key unpredictability.

[0119] Finally, the padded shared symmetric encryption key is used as a cyclically shifted shared symmetric encryption key. The key's shift strategy and padding byte position information are encrypted and stored in the client's dedicated private directory. Saving the shift strategy and padding information together ensures that the key structure can be fully restored upon subsequent use. Storing the key in a dedicated private directory further enhances key security, preventing unauthorized access.

[0120] Through the above steps, this embodiment effectively enhances the security of the shared symmetric encryption key on the client side. Circular shifting and XOR operations eliminate any fixed key pattern, increasing the difficulty of decryption. Padding further enhances the key's unpredictability, and by storing the key in a dedicated private directory, key security is ensured. Ultimately, these operations ensure that the key cannot be decrypted or tampered with during storage, transmission, and use, significantly improving the security of communication data encryption.

[0121] In one embodiment, the above step S502 includes:

[0122] S5021, generating an obfuscation seed based on the client's device identifier and the current session identifier;

[0123] S5022, inputting the obfuscation seed into a preset hash algorithm to generate an initial obfuscation factor sequence;

[0124] S5023: truncate or pad the initial confusion factor sequence according to the byte length of the shared symmetric encryption key after the cyclic shift processing to generate a confusion factor with an adapted length;

[0125] S5024, performing a bit-by-bit exclusive OR operation on the length-adapted obfuscation factor and the byte sequence of the shared symmetric encryption key after the cyclic shift processing to generate an intermediate obfuscated shared symmetric encryption key;

[0126] S5025: performing a bitwise AND operation on the byte sequence of the intermediate obfuscated shared symmetric encryption key and a preset session mask parameter to generate the obfuscated shared symmetric encryption key as the anti-extraction shared symmetric encryption key;

[0127] S5026: Encrypt the obfuscation seed and session mask parameters and store them in the client's exclusive private directory.

[0128] In this embodiment, during the anti-extraction process, obfuscation can further enhance key security, ensuring that the generated key cannot be easily extracted or cracked. This process involves combining the client's device identifier and session identifier to generate an obfuscation seed, which is then combined with the key through a series of processing steps to effectively obfuscate the shared symmetric encryption key.

[0129] First, the generation of the obfuscation seed relies on the client's device ID and the current session ID. The device ID is a unique identifier for each device (such as the IMEI number, UUID, or device ID), which ensures the uniqueness and device binding of the key. The session ID represents the current communication session and is typically generated jointly by the client and server and remains consistent throughout the session. By combining these two identifiers to form the obfuscation seed, we can effectively provide a dynamic factor for key encryption, preventing the security vulnerabilities associated with static key encryption methods.

[0130] Specifically, the obfuscation seed is created by concatenating the device ID and session ID, then applying a hash algorithm (such as SHA-256) to generate a fixed-length hash value. This ensures that each generated obfuscation seed varies based on the device and session, eliminating the risk of deducing the key from known device or session information.

[0131] Next, the obfuscation seed is hashed to generate the initial obfuscation factor sequence. The hash algorithm is irreversible and has strong hashing properties, ensuring the high randomness of the obfuscation factor sequence. This process ensures that even if an attacker obtains the device and session IDs, they cannot reverse engineer the obfuscation factor sequence.

[0132] To ensure that the length of the obfuscation factor sequence matches the byte length of the shared symmetric encryption key, the obfuscation factor sequence needs to be lengthened. This is typically accomplished through truncation or padding. If the obfuscation factor sequence is shorter than the byte length of the shared symmetric encryption key, the sequence can be lengthened by adding zero padding or specific pseudo-random bytes. Conversely, the sequence can be shortened by truncating the excess bytes. This ensures a one-to-one correspondence between the obfuscation factor and the encryption key byte sequence.

[0133] The generated obfuscation factor is then subjected to a bit-by-bit XOR operation with the cyclically shifted shared symmetric encryption key byte sequence. The XOR operation is a cryptographic technique that generates a new bit by comparing two bits. For identical bits, the XOR result is 0; for different bits, the XOR result is 1. In this way, the obfuscation factor is combined with the shared symmetric encryption key byte sequence to generate an intermediate obfuscated shared symmetric encryption key. This operation ensures that even if an attacker obtains the shared symmetric encryption key and part of the obfuscation factor, they cannot directly restore the original key data. The XOR operation is irreversible. Only by obtaining the complete obfuscation factor and key data can the correct key be recovered.

[0134] To further enhance encryption strength, the intermediate obfuscated shared symmetric encryption key is then bitwise ANDed with the session mask parameter. The session mask parameter is typically generated based on the session state, has a certain degree of randomness, and can change during the session. This step further perturbs the intermediate obfuscated key through the bitwise AND operation, complicating the encryption process and further enhancing key security. The bitwise AND operation is a bit-level operation; it retains only bits that are 1 in both operands and sets all other bits to 0. This process further disrupts the key's data structure, making it even more difficult to derive the key data.

[0135] After completing the above processing, the generated obfuscated shared symmetric encryption key becomes the extraction-resistant shared symmetric encryption key. This key undergoes multiple layers of processing, including cyclic shifts, obfuscation, and bitwise AND operations, increasing its complexity and significantly improving its security.

[0136] Finally, to ensure the security of the key generation process and possible subsequent key recovery operations, key information from the generation process (such as the obfuscation seed and session mask parameters) must be encrypted and stored in a dedicated private directory on the client. This information will be used to regenerate the same obfuscation factor and key during key recovery, ensuring the correctness and integrity of the key.

[0137] This embodiment uses multiple processing methods to prevent the shared symmetric encryption key from being extracted, including circular shifts, obfuscation factor generation, and bitwise AND operations. This not only increases the complexity of the key but also ensures its security through encrypted storage. These measures make it difficult for an attacker to recover the complete encryption key, even if they can obtain partial key data, greatly improving communication security.

[0138] In one embodiment, after the above step S60, the method further includes:

[0139] S701, configuring a total validity period for the shared symmetric encryption key after anti-extraction processing as an automatic expiration time threshold, and recording a key generation timestamp;

[0140] S702, analyzing the remaining validity period of the shared symmetric encryption key after the anti-extraction processing based on the automatic expiration time threshold and the key generation timestamp;

[0141] S703, when the remaining validity period is lower than a preset renegotiation trigger threshold, initiating a key renegotiation request to the server;

[0142] S704, monitoring the call frequency of the shared symmetric encryption key after the anti-extraction process, and adjusting the automatic expiration time threshold according to the call frequency;

[0143] S705, when a client restart event or an environmental security risk event is detected, the current shared symmetric encryption key after anti-extraction processing is discarded and a key regeneration process is triggered;

[0144] S706: Encrypt and store the automatic expiration time threshold, call frequency, and environmental security risk event records in a dedicated private directory of the client.

[0145] In this embodiment, key security is crucial during communication between the client and the server. To ensure the long-term security of the key and prevent it from being cracked or abused during use, this embodiment implements lifecycle management of the shared symmetric encryption key after anti-extraction processing to adapt to different security requirements and usage scenarios.

[0146] First, a total validity period is configured for the shared symmetric encryption key after anti-extraction processing, which serves as the automatic expiration threshold. Setting a total validity period effectively limits the key's usage and prevents potential security risks from long-term use. This validity period is configured by recording the key's generation timestamp, which marks the start time of the key's use. The timestamp generation process relies on the system clock, ensuring that each key generation is consistent with the current time and that timestamp generation is synchronized.

[0147] Based on the automatic expiration threshold and the key generation timestamp, the remaining validity period is analyzed by calculating the difference between the current time and the key generation timestamp. This remaining validity period calculation method ensures flexible and accurate key lifecycle management, allowing the system to adjust the key validity based on real-time time data. When the remaining validity period falls below the preset renegotiation trigger threshold, the system will initiate a key renegotiation request to the server. This process ensures that the client and server can regenerate a new shared key in a timely manner when the key validity period nears its end, thus avoiding the security risks that may arise from key expiration.

[0148] One of the key innovations of this technology is real-time monitoring of the frequency of shared symmetric encryption key usage, and dynamically adjusting the automatic expiration threshold based on the monitoring results. By continuously monitoring key usage frequency, the system can flexibly adjust the key validity period based on actual communication intensity. For example, when a key is frequently used, the system will shorten its validity period to reduce the potential attack surface; when it is less frequently used, the validity period will be appropriately extended to improve system performance and efficiency. This approach breaks the limitations of traditional static validity periods and provides a mechanism for real-time adjustment based on usage.

[0149] Upon detecting a client reboot or environmental security risk, the system discards the current shared symmetric encryption key and triggers a key regeneration process. This step is a rapid response to potential security threats, ensuring that the old key cannot be used for communication after a client reboot or attack, thus preventing key leakage or misuse.

[0150] Finally, all key lifecycle management information, including automatic expiration thresholds, call frequency, and environmental security risk events, is encrypted and stored in the client's dedicated private directory. This information is stored to ensure data integrity and immutability, and to provide a reliable basis for subsequent audits or key recovery.

[0151] This embodiment significantly enhances the security of communication data by configuring automatic expiration thresholds for shared symmetric encryption keys, monitoring call frequency, dynamically adjusting validity periods, and forcing key updates when abnormal events are detected. This prevents keys from being used for extended periods or being attacked. These measures provide a flexible and efficient key lifecycle management solution, significantly improving the system's ability to respond to security threats.

[0152] In one embodiment, after the above step S30, the method further includes:

[0153] S3001: If verification of the digital signature of the server public key fails, destroy the server public key and temporary key data related to the current session cached locally on the client, and record the destruction operation;

[0154] S3002, generating a security log including a verification failure event, and storing the security log in a non-volatile memory of the client;

[0155] S3003, closing the transport layer protocol socket connection between the client and the server, and sending a connection termination request message to the server;

[0156] S3004: If no confirmation response is received from the server to the connection termination request message, the network port resources of the client are forcibly released;

[0157] S3005, clearing the unsent or unreceived communication data in the client's memory buffer;

[0158] S3006, prohibiting re-establishment of the communication connection between the client and the server during a preset cooling-off period;

[0159] S3007: Push a security warning notification through the client's user interface, indicating that the server authentication failed;

[0160] S3008, encrypting and storing the security log, the preset cooling period, and the network port resource release record in the client's exclusive private directory.

[0161] In this embodiment, during the communication data encryption process, verification of the server public key is crucial. Once the public key verification fails, the system needs to take a series of security measures to prevent potential attacks and ensure communication security.

[0162] When the digital signature verification of the server's public key fails, the system first destroys the client's locally cached server public key and the temporary key data associated with the current session. This is to prevent attackers from exploiting compromised keys to conduct malicious operations. The server's public key stored on the client is typically used to establish trust and encrypt communications. If verification fails, retaining this data increases potential security risks. Therefore, by immediately destroying this data, the system ensures that it cannot be further misused.

[0163] To ensure event tracking and auditing, the system generates a security log containing verification failure events and stores it in the client's non-volatile memory. This operation is intended to provide data support for subsequent security incident investigations. By recording the log information of server-side public key verification failures, administrators or security teams can promptly analyze the source of the attack and improve the system's security policies. Unlike traditional log storage methods, the security log generated here is encrypted to prevent the leakage of sensitive information.

[0164] Once the server's public key verification fails, the system closes the transport layer protocol socket connection between the client and server. Transport layer protocols (such as TCP / IP) are responsible for data transmission. If authentication fails, maintaining the connection increases the chances of an attack. Therefore, closing the connection by the client is the first step in ensuring data security. Simultaneously, the client sends a connection termination request message to the server, formally terminating communication and preventing further data exchange.

[0165] If the client does not receive a confirmation response from the server to the connection termination request, the system will forcibly release the client's network port resources. This action prevents the network port from being occupied for an extended period of time, ensuring that the system can return to normal operation and avoiding resource waste or denial of service attacks caused by the server's failure to respond. After the forced release of the port resources, the client will be able to continue normal network operations without being affected by the failure.

[0166] To prevent sensitive data from being leaked or misused, the client clears unsent or unreceived communication data from its memory buffer. Buffers are typically used to temporarily store data in transit. If verification fails, all data stored in memory is cleared, preventing malware or attackers from exploiting cached data for data recovery or analysis.

[0167] To further strengthen security, if a client detects a server authentication failure, the system will prohibit reestablishing a communication connection between the client and the server for a preset cooldown period. This cooldown period effectively prevents attackers from circumventing security measures through frequent connection attempts, while also providing the system with ample time to detect and correct any anomalies.

[0168] To inform users of authentication failures and ensure security, the system pushes security warning notifications through the client's user interface. These notifications inform users of server-side authentication failures and recommend appropriate security measures, such as restarting the connection or checking the server's certificate. This allows users to directly understand the system's security status and respond promptly.

[0169] Finally, all sensitive data related to the incident, including security logs, cooldown period settings, and network port resource release records, is encrypted and stored in the client's dedicated private directory. This ensures information security and prevents unauthorized access or tampering. Through encrypted storage, the system protects critical security incident information and provides reliable evidence for subsequent incident investigations.

[0170] This embodiment effectively prevents attackers from exploiting expired public keys to conduct man-in-the-middle attacks or other malicious activities by promptly responding to server-side public key verification failures and managing system resources. By clearing sensitive data, forcing disconnections, storing security logs, and forcing key updates, this method enhances communication security. The system's adaptive cooldown period and network port resource release policy effectively limit further attacker activity, enhancing protection capabilities.

[0171] In one embodiment, the above step S40 includes:

[0172] S401, when the digital signature of the server public key is verified, using an elliptic curve multiplication module to determine the product of the client private key and the server public key to generate an intermediate shared key;

[0173] S402, performing an XOR operation on the intermediate shared key and the device identifier of the client to generate a mixed intermediate shared key;

[0174] S403, performing a hash operation and an expansion process on the mixed intermediate shared key based on a preset key derivation function to generate an initial symmetric encryption key;

[0175] S404: Concatenate the initial symmetric encryption key with the current session identifier, and perform normalization on the concatenated data to generate a final shared symmetric encryption key;

[0176] S405: Encrypt and store the parameters of the elliptic curve multiplication module, the device identifier, and the current session identifier in a dedicated private directory of the client.

[0177] In this embodiment, a shared symmetric encryption key is generated based on the client private key and the server public key. This key will be used to encrypt the communication between the client and the server.

[0178] First, the client performs an elliptic curve multiplication using its private key and the public key provided by the server. Elliptic curve multiplication is a calculation based on elliptic curve cryptography (ECC). Through this calculation, the client and server generate a shared intermediate key. Compared to traditional public key algorithms (such as RSA), elliptic curve cryptography provides higher security and computational efficiency, and is more resistant to attacks with the same key length. This intermediate shared key serves as the basis for subsequent obfuscation and key derivation processes.

[0179] After generating the intermediate shared key, the client performs an XOR operation on the intermediate key with the device identifier to further enhance key security. The device identifier is typically unique and can be a serial number or hardware signature. This ties the key to the device, preventing different devices from sharing the same key. The XOR operation combines the bits of the two to create a "mixed intermediate shared key," making it more difficult to crack.

[0180] Next, the client hashes and expands the mixed intermediate shared key using a pre-defined key derivation function (KDF). The KDF generates a stronger symmetric encryption key from the original intermediate key. This process typically involves hashing, salting, and multiple iterations to ensure the final key is highly random and secure. This initial symmetric encryption key is then used as the final key to protect data in encrypted communications.

[0181] To ensure key uniqueness across sessions, the client concatenates the initial symmetric encryption key with the current session identifier. The session identifier is a unique identifier associated with the current session. It ensures that different keys are used across multiple sessions, even on the same device. The concatenated data is then normalized to ensure a consistent key format for subsequent encryption. The resulting shared symmetric encryption key can be securely used to encrypt communications between the client and the server.

[0182] Finally, to ensure the security of the generation process and key traceability, the client encrypts and stores the elliptic curve multiplication module parameters, device identifier, and current session identifier in a dedicated private directory. This information serves as auxiliary data for key recovery and provides essential information for subsequent security audits and key management. Data stored in the dedicated private directory can only be accessed by authorized programs or devices, ensuring data security and tamper resistance.

[0183] This embodiment combines the client's private key and the server's public key to generate a shared symmetric encryption key. This ensures the uniqueness of the key generated within each session and prevents key reuse across multiple devices or sessions. By introducing device identity obfuscation, key security is enhanced, effectively preventing key extraction and misuse by malicious attackers. Furthermore, the use of a key derivation function further enhances the complexity and randomness of key generation, providing strong security for communication encryption.

[0184] In one embodiment, a communication data encryption device is provided, which corresponds one-to-one to the communication data encryption method in the above embodiment. Figure 3 , Figure 3 This is a functional module diagram of a preferred embodiment of the communication data encryption device of the present invention. It includes a key generation module 10, a public key exchange module 20, a digital signature verification module 30, a key negotiation module 40, a key protection module 50, and an encryption processing module 60. Each functional module is described in detail below:

[0185] The key generation module 10 is used to generate an asymmetric key pair for the client, wherein the asymmetric key pair includes a client private key and a client public key;

[0186] The public key exchange module 20 is used to send the client public key to the server and receive the server public key and corresponding digital signature returned by the server;

[0187] A digital signature verification module 30 is used to verify the digital signature of the server public key through a pre-stored trusted root certificate;

[0188] A key negotiation module 40 is configured to generate a shared symmetric encryption key based on the client private key and the server public key when verification is successful;

[0189] A key protection module 50 is configured to perform anti-extraction processing on the shared symmetric encryption key, generate an anti-extraction shared symmetric encryption key, and store the key in a dedicated private directory of the client;

[0190] The encryption processing module 60 is used to encrypt the communication content between the client and the server according to the shared symmetric encryption key after the anti-extraction processing.

[0191] In one embodiment, the key protection module 50 is specifically configured to:

[0192] Performing a cyclic shift process on the byte sequence of the shared symmetric encryption key to generate a cyclically shifted shared symmetric encryption key;

[0193] generating an obfuscation factor based on the device identifier of the client, performing obfuscation processing on the shared symmetric encryption key after the cyclic shift processing based on the obfuscation factor, and generating the shared symmetric encryption key after the obfuscation processing as the shared symmetric encryption key after the anti-extraction processing;

[0194] Splitting the shared symmetric encryption key after the anti-extraction process into multiple key data blocks, and adding padding bytes to each key data block to match a preset storage length;

[0195] The multiple key data blocks are respectively stored in multiple scattered sub-paths of the exclusive private directory of the client, and an anti-tampering verification code is generated for each key data block.

[0196] In one embodiment, the key protection module 50 is specifically configured to:

[0197] Performing a cyclic shift operation on each byte of the shared symmetric encryption key according to a preset shift strategy to generate an initially shifted shared symmetric encryption key;

[0198] Performing an XOR operation on the byte sequence of the initially shifted shared symmetric encryption key and the device identification of the client to generate an intermediate shifted shared symmetric encryption key;

[0199] Inserting random padding bytes into the byte sequence of the shared symmetric encryption key after the intermediate shift to maintain the original key length, thereby generating a padded shared symmetric encryption key;

[0200] The padded shared symmetric encryption key is used as the shared symmetric encryption key after cyclic shift processing, and the preset shift strategy and the position information of the random padded bytes are encrypted and stored in the client's exclusive private directory.

[0201] In one embodiment, the key protection module 50 is specifically configured to:

[0202] Generate an obfuscated seed based on the client's device ID and current session ID;

[0203] Inputting the obfuscation seed into a preset hash algorithm to generate an initial obfuscation factor sequence;

[0204] Truncating or padding the initial confusion factor sequence according to the byte length of the shared symmetric encryption key after the cyclic shift processing to generate a confusion factor with an adapted length;

[0205] Performing a bit-by-bit XOR operation on the length-adapted obfuscation factor and the byte sequence of the shared symmetric encryption key after the cyclic shift process to generate an intermediate obfuscated shared symmetric encryption key;

[0206] Performing a bitwise AND operation on the byte sequence of the intermediate obfuscated shared symmetric encryption key and a preset session mask parameter to generate the obfuscated shared symmetric encryption key as the anti-extraction shared symmetric encryption key;

[0207] The obfuscation seed and session mask parameters are encrypted and stored in a dedicated private directory of the client.

[0208] In one embodiment, the encryption processing module 60 is specifically configured to:

[0209] Configuring a total validity period for the shared symmetric encryption key after the anti-extraction process as an automatic expiration time threshold, and recording a key generation timestamp;

[0210] Analyzing the remaining validity period of the shared symmetric encryption key after the anti-extraction processing based on the automatic expiration time threshold and the key generation timestamp;

[0211] When the remaining validity period is lower than a preset renegotiation trigger threshold, initiating a key renegotiation request to the server;

[0212] Monitoring the call frequency of the shared symmetric encryption key after the anti-extraction process, and adjusting the automatic expiration time threshold according to the call frequency;

[0213] When a client restart event or an environmental security risk event is detected, the current shared symmetric encryption key after anti-extraction processing is discarded and the key regeneration process is triggered;

[0214] The automatic expiration time threshold, call frequency and environmental security risk event records are encrypted and stored in the client's exclusive private directory.

[0215] In one embodiment, the digital signature verification module 30 is specifically configured to:

[0216] If verification of the digital signature of the server public key fails, the client locally caches the server public key and the temporary key data associated with the current session, and records the destruction operation;

[0217] Generate a security log containing verification failure events, and store the security log in a non-volatile memory of the client;

[0218] Closing the transport layer protocol socket connection between the client and the server, and sending a connection termination request message to the server;

[0219] If no confirmation response is received from the server to the connection termination request message, the client's network port resources are forcibly released;

[0220] Clean up the unsent or unreceived communication data in the client's memory buffer;

[0221] Prohibit re-establishment of the communication connection between the client and the server during the preset cooling-off period;

[0222] Push security warning notifications through the client's user interface, indicating that the server authentication failed;

[0223] The security log, preset cooling period and network port resource release record are encrypted and stored in the client's exclusive private directory.

[0224] In one embodiment, the key agreement module 40 is specifically configured to:

[0225] When the digital signature of the server public key is verified, the product of the client private key and the server public key is determined using the elliptic curve multiplication module to generate an intermediate shared key;

[0226] Performing an XOR operation on the intermediate shared key and the device identification of the client to generate a mixed intermediate shared key;

[0227] Performing hashing and expansion processing on the mixed intermediate shared key based on a preset key derivation function to generate an initial symmetric encryption key;

[0228] Concatenating the initial symmetric encryption key with the current session identifier and performing normalization processing on the concatenated data to generate a final shared symmetric encryption key;

[0229] The parameters of the elliptic curve multiplication module, the device identifier and the current session identifier are encrypted and stored in the client's exclusive private directory.

[0230] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, memory, network interface and database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external user terminal via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a communication data encryption method on the server side.

[0231] In one embodiment, a computer device is provided. The computer device may be a user terminal, and its internal structure diagram may be as follows: Figure 5 As shown. The computer device includes a processor, memory, network interface, display screen and input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a communication data encryption method on the user side.

[0232] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the following steps are performed:

[0233] Generate an asymmetric key pair for the client, wherein the asymmetric key pair includes a client private key and a client public key;

[0234] Send the client public key to the server, and receive the server public key and corresponding digital signature returned by the server;

[0235] Verify the digital signature of the server public key through a pre-stored trusted root certificate;

[0236] When the verification is successful, a shared symmetric encryption key is generated based on the client private key and the server public key;

[0237] Performing anti-extraction processing on the shared symmetric encryption key to generate an anti-extraction shared symmetric encryption key, and storing the key in a dedicated private directory of the client;

[0238] The communication content between the client and the server is encrypted according to the shared symmetric encryption key after the anti-extraction process.

[0239] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented:

[0240] Generate an asymmetric key pair for the client, wherein the asymmetric key pair includes a client private key and a client public key;

[0241] Send the client public key to the server, and receive the server public key and corresponding digital signature returned by the server;

[0242] Verify the digital signature of the server public key through a pre-stored trusted root certificate;

[0243] When the verification is successful, a shared symmetric encryption key is generated based on the client private key and the server public key;

[0244] Performing anti-extraction processing on the shared symmetric encryption key to generate an anti-extraction shared symmetric encryption key, and storing the key in a dedicated private directory of the client;

[0245] The communication content between the client and the server is encrypted according to the shared symmetric encryption key after the anti-extraction process.

[0246] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can be found in the relevant descriptions of the server side and the user side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0247] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0248] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0249] It should be noted that if any software tools or components other than those of the Company appear in the embodiments of this application, they are merely for illustration and do not represent actual use. The above embodiments are intended only to illustrate the technical solutions of the present invention, not to limit them. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some of the technical features therein with equivalents. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the scope of protection of the present invention.

Claims

1. A communication data encryption method, characterized in that: The following steps are involved: Generate an asymmetric key pair for the client, wherein the asymmetric key pair includes a client private key and a client public key; Send the client public key to the server, and receive the server public key and corresponding digital signature returned by the server; Verify the digital signature of the server public key through a pre-stored trusted root certificate; When the verification is successful, a shared symmetric encryption key is generated based on the client private key and the server public key; Performing anti-extraction processing on the shared symmetric encryption key to generate an anti-extraction shared symmetric encryption key, and storing the key in a dedicated private directory of the client; The communication content between the client and the server is encrypted according to the shared symmetric encryption key after the anti-extraction process.

2. The communication data encryption method according to claim 1, wherein: Performing anti-extraction processing on the shared symmetric encryption key to generate an anti-extraction shared symmetric encryption key and storing it in a dedicated private directory of the client, including: Performing a cyclic shift process on the byte sequence of the shared symmetric encryption key to generate a cyclically shifted shared symmetric encryption key; generating an obfuscation factor based on the device identifier of the client, performing obfuscation processing on the shared symmetric encryption key after the cyclic shift processing based on the obfuscation factor, and generating the shared symmetric encryption key after the obfuscation processing as the shared symmetric encryption key after the anti-extraction processing; Splitting the shared symmetric encryption key after the anti-extraction process into multiple key data blocks, and adding padding bytes to each key data block to match a preset storage length; The multiple key data blocks are respectively stored in multiple scattered sub-paths of the exclusive private directory of the client, and an anti-tampering verification code is generated for each key data block.

3. The communication data encryption method according to claim 2, wherein: Performing a cyclic shift process on the byte sequence of the shared symmetric encryption key to generate a cyclically shifted shared symmetric encryption key, comprising: Performing a cyclic shift operation on each byte of the shared symmetric encryption key according to a preset shift strategy to generate an initially shifted shared symmetric encryption key; Performing an XOR operation on the byte sequence of the initially shifted shared symmetric encryption key and the device identification of the client to generate an intermediate shifted shared symmetric encryption key; Inserting random padding bytes into the byte sequence of the shared symmetric encryption key after the intermediate shift to maintain the original key length, thereby generating a padded shared symmetric encryption key; The padded shared symmetric encryption key is used as the shared symmetric encryption key after cyclic shift processing, and the preset shift strategy and the position information of the random padded bytes are encrypted and stored in the client's exclusive private directory.

4. The communication data encryption method according to claim 2, wherein: Generating an obfuscation factor based on a device identifier of the client, performing obfuscation processing on the shared symmetric encryption key after the cyclic shift processing based on the obfuscation factor, and generating the shared symmetric encryption key after the obfuscation processing as the shared symmetric encryption key after the anti-extraction processing, including: Generate an obfuscated seed based on the client's device ID and current session ID; Inputting the obfuscation seed into a preset hash algorithm to generate an initial obfuscation factor sequence; Truncating or padding the initial confusion factor sequence according to the byte length of the shared symmetric encryption key after the cyclic shift processing to generate a confusion factor with an adapted length; Performing a bit-by-bit XOR operation on the length-adapted obfuscation factor and the byte sequence of the shared symmetric encryption key after the cyclic shift process to generate an intermediate obfuscated shared symmetric encryption key; Performing a bitwise AND operation on the byte sequence of the intermediate obfuscated shared symmetric encryption key and a preset session mask parameter to generate the obfuscated shared symmetric encryption key as the anti-extraction shared symmetric encryption key; The obfuscation seed and session mask parameters are encrypted and stored in a dedicated private directory of the client.

5. The communication data encryption method according to claim 1, wherein: After encrypting the communication content between the client and the server according to the shared symmetric encryption key after the anti-extraction process, the method further includes: Configuring a total validity period for the shared symmetric encryption key after the anti-extraction process as an automatic expiration time threshold, and recording a key generation timestamp; Analyzing the remaining validity period of the shared symmetric encryption key after the anti-extraction processing based on the automatic expiration time threshold and the key generation timestamp; When the remaining validity period is lower than a preset renegotiation trigger threshold, initiating a key renegotiation request to the server; Monitoring the call frequency of the shared symmetric encryption key after the anti-extraction process, and adjusting the automatic expiration time threshold according to the call frequency; When a client restart event or an environmental security risk event is detected, the current shared symmetric encryption key after anti-extraction processing is discarded and the key regeneration process is triggered; The automatic expiration time threshold, call frequency and environmental security risk event records are encrypted and stored in the client's exclusive private directory.

6. The communication data encryption method according to claim 1, wherein: After verifying the digital signature of the server public key through the pre-stored trusted root certificate, it also includes: If verification of the digital signature of the server public key fails, the client locally caches the server public key and the temporary key data associated with the current session, and records the destruction operation; Generate a security log containing the verification failure event, and store the security log in a non-volatile memory of the client; Closing the transport layer protocol socket connection between the client and the server, and sending a connection termination request message to the server; If no confirmation response is received from the server to the connection termination request message, the client's network port resources are forcibly released; Clean up the unsent or unreceived communication data in the client's memory buffer; Prohibit re-establishment of the communication connection between the client and the server during the preset cooling-off period; Push security warning notifications through the client's user interface, indicating that the server authentication failed; The security log, preset cooling period and network port resource release record are encrypted and stored in the client's exclusive private directory.

7. The communication data encryption method according to claim 1, wherein: When the verification is successful, a shared symmetric encryption key is generated based on the client private key and the server public key, including: When the digital signature of the server public key is verified, the product of the client private key and the server public key is determined using the elliptic curve multiplication module to generate an intermediate shared key; Performing an XOR operation on the intermediate shared key and the device identification of the client to generate a mixed intermediate shared key; Performing hashing and expansion processing on the mixed intermediate shared key based on a preset key derivation function to generate an initial symmetric encryption key; Concatenating the initial symmetric encryption key with the current session identifier and performing normalization processing on the concatenated data to generate a final shared symmetric encryption key; The parameters of the elliptic curve multiplication module, the device identifier and the current session identifier are encrypted and stored in the client's exclusive private directory.

8. A communication data encryption device, characterized in that: The communication data encryption device comprises: A key generation module is used to generate an asymmetric key pair for the client, wherein the asymmetric key pair includes a client private key and a client public key; A public key exchange module, configured to send the client public key to the server and receive the server public key and corresponding digital signature returned by the server; A digital signature verification module, used to verify the digital signature of the server public key through a pre-stored trusted root certificate; A key negotiation module, configured to generate a shared symmetric encryption key based on the client private key and the server public key when verification is successful; A key protection module, configured to perform anti-extraction processing on the shared symmetric encryption key, generate an anti-extraction shared symmetric encryption key, and store the key in a dedicated private directory of the client; The encryption processing module is used to encrypt the communication content between the client and the server according to the shared symmetric encryption key after the anti-extraction processing.

9. A computer device, characterized in that: The computer device includes a memory, a processor, and a communication data encryption program stored in the memory and capable of running on the processor. When the communication data encryption program is executed by the processor, the steps of the communication data encryption method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that The storage medium stores a communication data encryption program, which, when executed by a processor, implements the steps of the communication data encryption method according to any one of claims 1 to 7.

Images