A BS architecture system request shell encryption method and system based on a national secret algorithm
By using a request shell encryption method based on national cryptographic algorithms in a B/S architecture system, combined with SM4, SM2, and SM3 algorithms and dynamic key management, the performance bottleneck and security issues of data transmission under high load conditions are solved, and an efficient and secure data transmission solution is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SHANGHAI OFFICE WORKER DIGITAL TECH CO LTD
- Filing Date
- 2024-12-31
- Publication Date
- 2026-07-21
AI Technical Summary
Existing encryption technologies suffer from performance bottlenecks under high load and high traffic environments, making it difficult to effectively prevent data leakage, tampering, and replay attacks. Furthermore, they do not provide comprehensive support for prioritizing sensitive data and managing dynamic keys.
The system adopts a request shell encryption method based on Chinese cryptographic algorithms in a B/S architecture. It includes a client request shell module, a server encryption/decryption gateway module, a key management module, and a data storage module. Data encryption, decryption, and signing are performed using SM4, SM2, and SM3 algorithms. Combined with dynamic key management and priority processing mechanisms, it ensures the secure transmission of sensitive data.
It improves the security and efficiency of data transmission, ensuring the security and reliability of highly sensitive data in complex network environments, and is applicable to fields such as finance and government affairs.
Smart Images
Figure CN119788392B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of data encryption and decryption technology, and more specifically, to a request shell encryption method and system for a B / S architecture system based on Chinese national cryptographic algorithms. Background Technology
[0002] In the current field of information security, with the widespread adoption of internet applications, data transmission security has become increasingly prominent. Traditional encryption technologies often struggle to effectively prevent data leakage, tampering, and replay attacks when faced with complex network attacks. Especially when handling sensitive data (such as in finance, healthcare, and government affairs), ensuring the confidentiality, integrity, and authentication of data during transmission has become a critical issue that urgently needs to be addressed. With the increasing emphasis on information security by the state, national cryptographic algorithms (such as SM4, SM2, and SM3) have gradually become the standard for domestic information protection. However, existing encryption methods may experience performance bottlenecks under high load and high traffic environments, and their support for prioritizing sensitive data and dynamic key management is not comprehensive enough. Therefore, how to improve system efficiency while ensuring security has become a major challenge in current technology. To address this issue, this invention proposes a request shell encryption scheme for a B / S architecture system based on national cryptographic algorithms. Combining encryption algorithms, priority processing, and dynamic key management mechanisms, it aims to provide a more secure and efficient data transmission solution.
[0003] To address the above problems, this invention proposes a solution. Summary of the Invention
[0004] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a method and system for encrypting request shells in a BS architecture system based on national cryptographic algorithms, in order to solve the problems mentioned in the background art.
[0005] To achieve the above objectives, the present invention provides the following technical solution:
[0006] In a preferred embodiment, it includes: a client request shell module, a server encryption / decryption gateway module, a key management module, a data storage module, and signal connections between the modules;
[0007] The client request shell module mainly encrypts the user request body using SM4, decrypts the encrypted response body returned by the server, generates a signature for the request data, and sends the encrypted request data to the server encryption / decryption gateway module. It also scores the request data based on its sensitivity and timeliness, calculates a priority value, and ensures that sensitive and urgent requests are encrypted and transmitted first.
[0008] The server-side encryption / decryption gateway module is mainly used to receive encrypted request data transmitted by clients over the network, decrypt the requests and verify the signatures. It is also responsible for uniformly encrypting the response data of the business server and designing filter plugins.
[0009] The key management module is mainly used to design dynamic key management and key rotation mechanisms: automatically generating, distributing, using and updating keys, and periodically replacing keys during their lifecycle;
[0010] The data storage module is used to store all data processed by each module.
[0011] In a preferred embodiment, in the client request shell module, the browser plugin intercepts HTTP requests via the WebExtension API and uses the webRequest API to listen for and modify request data; the mobile SDK intercepts network requests within the WebView and intercepts and rewrites XMLHttpRequest or fetch in the WebView component;
[0012] The steps to encrypt and decrypt the request body data using the SM4 algorithm are as follows:
[0013] Step S1: Serialize the request data into JSON format;
[0014] Step S2: Encrypt the data using a symmetric key;
[0015] Step S3: Generate an integrity verification code for the encrypted data;
[0016] Step S4: Sign the request data using the SM2 private key and append it to the request header;
[0017] Step S5: After receiving the encrypted data returned by the server, use SM4 to decrypt the response body and verify the integrity check code.
[0018] In a preferred embodiment, the client request shell module establishes a scoring mechanism to classify the sensitivity of requested data into different levels based on the importance of the data content: high sensitivity; medium sensitivity; low sensitivity.
[0019] Set thresholds Ym1, Ym2, and Ym3. When the sensitivity score of the requested data is greater than or equal to Ym1 and less than Ym2, the requested data is considered low-sensitivity data; when the sensitivity score of the requested data is greater than or equal to Ym2 and less than Ym3, the requested data is considered medium-sensitivity data; when the sensitivity score of the requested data is greater than or equal to Ym3, the requested data is considered high-sensitivity data.
[0020] Based on the response time requirements, the timeliness of requested data is categorized into different levels: high timeliness; medium timeliness; low timeliness.
[0021] Thresholds Yt1, Yt2, and Yt3 are set. When the timeliness score of the requested data is greater than or equal to Yt1 and less than Yt2, the requested data is considered low timeliness; when the timeliness score of the requested data is greater than or equal to Yt2 and less than Yt3, the requested data is considered medium timeliness; and when the timeliness score of the requested data is greater than or equal to Yt3, the requested data is considered high timeliness.
[0022] The client request shell module calculates the priority value of each request data by using a weighted average of the sensitivity score and timeliness score of each request data, according to the formula: YXZ=Qm×M+Qsx×SX, where YXZ represents the priority value of each request data, Qm represents the weight of the sensitivity score of each request data, M represents the sensitivity score of each request data, Qsx represents the weight of the timeliness score of each request data, and SX represents the timeliness score of each request data.
[0023] In a preferred embodiment, the steps for decrypting client request data are as follows:
[0024] Step D1: The server-side encryption / decryption gateway module listens on the network port through the gateway, receives requests sent by the client via the HTTPS protocol, and extracts encrypted data from the received requests;
[0025] Step D2: The server-side encryption / decryption gateway module extracts the JSON format data sent by the client, uses a JSON parsing library to decode the data from the network transmission format into an operable structure, and checks whether the timestamp matches the server time;
[0026] Step D3: The server-side encryption / decryption gateway module obtains the symmetric key for the current session and uses the session key to decrypt the encrypted data using the SM4 algorithm;
[0027] Step D4: For the decrypted plaintext data, use the SM3 hash algorithm to generate a data digest, and compare the locally generated hash value with the hash field provided by the client;
[0028] Step D5: Encapsulate the decrypted plaintext data according to an HTTP POST request; and transmit it to the business server via the HTTP / HTTPS network protocol;
[0029] The steps for the encrypted service server to respond with data are as follows:
[0030] Step F1: After receiving the response data from the business server, the server-side encryption / decryption network management module uses a symmetric encryption algorithm and the session key to encrypt the response data.
[0031] Step F2: Sign the encrypted response data using the private key of the SM2 algorithm to generate a digital signature.
[0032] Step F3: After receiving the encrypted response data and digital signature, the client request shell module first verifies the digital signature, then decrypts the response body content using the symmetric key, and finally verifies the integrity of the data based on the hash value.
[0033] In a preferred embodiment, upon receiving a request, the filter plugin first checks the encryption of the request data; then it checks the digital signature in the request; if the signature is invalid, the request is rejected directly; the filter plugin extracts the timestamp from the request and compares it with the server's current time; if the timestamp is not within the valid range, it is considered a replay attack, and the filter rejects the request; the filter plugin further analyzes the source IP address and frequency of the request, detects abnormal behavior, triggers a restriction or warning mechanism; if the request data passes all verifications, the filter plugin allows the request to continue into the backend service; otherwise, it rejects the request and records the abnormal information.
[0034] In a preferred embodiment, the key generation process is as follows:
[0035] The key management module's hardware random number generator collects unpredictable physical signals, generates keys using the SM4 or SM2 standard, performs hash operations on the keys using a hash algorithm to generate unique hash values, and compares them with the hash values already stored in the database.
[0036] The key distribution process is as follows:
[0037] The key management module uses the public key of the SM2 asymmetric encryption algorithm to encrypt the key, generate a timestamp T1, and append it to the encryption key. The key management module compares the time requested by the receiver with the timestamp; the key is transmitted using the TLS encryption protocol and the HTTPS secure transmission protocol.
[0038] The key usage process is as follows:
[0039] The key management module stores the key in a protected memory area and uses a memory protection mechanism to prevent other processes from accessing it; physical protection is provided by the HSM hardware security module. Meanwhile, the client only loads the key when needed and cleans it up immediately after use. SM4 uses a symmetric encryption algorithm to encrypt or decrypt data using the key.
[0040] The key management module is designed with a key lifecycle management mechanism, a security event detection and response mechanism, a distribution mechanism, and a rollback mechanism.
[0041] Key lifecycle management mechanism: By setting the validity period or number of uses of a key, the key will be automatically updated after the set threshold is reached;
[0042] Security incident detection and response mechanism: The system security status is monitored in real time through log auditing and abnormal traffic analysis, and key updates are triggered when an anomaly is detected;
[0043] Distribution and rollback mechanisms: The new key is transmitted in encrypted form, and if the transmission fails, it is rolled back to the previous valid key.
[0044] In a preferred embodiment, step 1: the request body is encrypted using the SM4 algorithm, the hash value is generated by SM3 to verify the data integrity, and the signature by SM2 ensures that the data source is trustworthy;
[0045] Step 2: Score the requested data based on its sensitivity and timeliness, calculate priority values, and ensure that sensitive and urgent requests are encrypted and transmitted first.
[0046] Step 3: Decrypt and verify data integrity using SM4, then encrypt the response data using SM4 and sign it using SM2 to ensure the data is returned securely.
[0047] Step 4: Design a dynamic key management and key rotation mechanism: automatically generate, distribute, use and update keys to ensure that an independent key is used for each communication and flexibly adjust the key usage strategy; change keys periodically or under specific conditions during the key lifecycle.
[0048] This invention discloses a request shell encryption method and system for a B / S architecture system based on national cryptographic algorithms, belonging to the field of data encryption and decryption technology, and used to solve the problems of unsatisfactory data transmission security and efficiency. It includes: a client request shell module, a server encryption / decryption gateway module, a key management module, a data storage module, and signal connections between the modules. The client request shell module encrypts the request data and verifies its integrity. The server encryption / decryption gateway module receives the encryption request, decrypts it, and verifies the data integrity. The key management module adopts a dynamic key generation and rotation mechanism, periodically updating the key to improve system security. Priorities are set according to the sensitivity and timeliness of the requests to ensure that important data is encrypted and transmitted first. This invention provides an efficient and secure data transmission scheme by comprehensively utilizing national cryptographic algorithms and priority processing mechanisms, and can be widely used in highly sensitive data processing scenarios such as finance and government affairs. Attached Figure Description
[0049] Figure 1 This is a schematic diagram of the request shell encryption system structure of a BS architecture system based on national cryptographic algorithms according to the present invention.
[0050] Figure 2 This is a flowchart illustrating the operation of a request shell encryption method for a B / S architecture system based on national cryptographic algorithms, as described in this invention. Detailed Implementation
[0051] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0052] Example: This invention discloses a request shell encryption system for a B / S architecture system based on Chinese cryptographic algorithms, including: a client request shell module, a server encryption / decryption gateway module, a key management module, and a data storage module, with signal connections between the modules.
[0053] The data storage module is used to store all data processed by each module.
[0054] The client request module is mainly used to ensure data integrity, protect request data, prevent sensitive information from being stolen or tampered with, and generate a signature for the request data by encrypting the user request body using SM4, decrypting the encrypted response body returned by the server, and sending the encrypted request data to the server-side encryption / decryption gateway module.
[0055] In the client-side request shell module, the browser plugin intercepts HTTP requests via the WebExtension API and uses the webRequest API to listen for and modify request data. The mobile SDK intercepts network requests within the WebView and intercepts and rewrites XMLHttpRequest or fetch within the WebView component. This enhances control and ensures that all request data is encrypted.
[0056] The client request shell module uses the SM4 algorithm to encrypt and decrypt the request body data. The specific steps are as follows:
[0057] Step S1: Serialize the request data into JSON format.
[0058] Step S2: Encrypt the data using a symmetric key (SM4).
[0059] Step S3: Generate an integrity check code (SM3 hash value) for the encrypted data.
[0060] Step S4: Sign the request data using the SM2 private key and append it to the request header.
[0061] Step S5: After receiving the encrypted data returned by the server, use SM4 to decrypt the response body and verify the integrity check code.
[0062] To optimize system efficiency and security, especially in high-load, high-traffic environments, reasonable priority processing can ensure that critical requests are processed in a timely and secure manner. In this embodiment, the priority of request data is determined based on the sensitivity and timeliness of the request data, and high-priority request data is encrypted and transmitted first to improve operational efficiency.
[0063] Specifically, the client request shell module establishes a scoring mechanism to measure the sensitivity and timeliness of each request data using quantifiable standards.
[0064] In this embodiment, the sensitivity of the requested data is divided into different levels according to the importance of the data content: high sensitivity; medium sensitivity; low sensitivity.
[0065] Set thresholds Ym1, Ym2, and Ym3. When the sensitivity score of the requested data is greater than or equal to Ym1 and less than Ym2, the requested data is considered low-sensitivity data; when the sensitivity score of the requested data is greater than or equal to Ym2 and less than Ym3, the requested data is considered medium-sensitivity data; when the sensitivity score of the requested data is greater than or equal to Ym3, the requested data is considered high-sensitivity data.
[0066] Based on the response time requirements, the timeliness of requested data is divided into different levels: high timeliness; medium timeliness; low timeliness.
[0067] Thresholds Yt1, Yt2, and Yt3 are set. When the timeliness score of the requested data is greater than or equal to Yt1 and less than Yt2, the requested data is considered low timeliness; when the timeliness score of the requested data is greater than or equal to Yt2 and less than Yt3, the requested data is considered medium timeliness; and when the timeliness score of the requested data is greater than or equal to Yt3, the requested data is considered high timeliness.
[0068] For example, the request data obtained by the client request shell module is as follows:
[0069] Request A:
[0070] Data content: The user requests to transfer 10,000 yuan from account A to account B.
[0071] Sensitivity: High (involves user funds).
[0072] Timeliness: High (requires real-time processing).
[0073] Request B (Balance Inquiry Request):
[0074] Data content: The user wants to check their account balance.
[0075] Sensitivity: Medium (involves privacy but low risk).
[0076] Timeliness: Medium (requires rapid response but not real-time).
[0077] Request C (Log Upload Request):
[0078] Data content: System-uploaded operation logs for backend analysis.
[0079] Sensitivity: Low (no sensitive information).
[0080] Timeliness: Low (non-real-time).
[0081] The client-side request shell module quantifies the sensitivity and timeliness of each request data based on a scoring mechanism, as shown in the following example data:
[0082] Request A:
[0083] Sensitivity score: 10;
[0084] Timeliness rating: 10;
[0085] Request B:
[0086] Sensitivity score: 7;
[0087] Timeliness rating: 6;
[0088] Request C:
[0089] Sensitivity score: 2;
[0090] Timeliness score: 2;
[0091] Furthermore, the client-side request shell module calculates the priority value of each request data using a weighted average of its sensitivity and timeliness scores. Through reasonable weight allocation, the two dimensions of sensitivity and timeliness are combined into a single priority value. Specifically, the formula is: YXZ = Qm × M + Qsx × SX, where YXZ represents the priority value of each request data, Qm represents the weight of the sensitivity score, M represents the sensitivity score, Qsx represents the weight of the timeliness score, and SX represents the timeliness score. For example, if Qm is calculated to be 0.7 and Qsx to be 0.3, substituting the example data, the priority value of request A is 10, the priority value of request B is 6.3, and the priority value of request C is 2. Comparing these priority values, the priority order is: Request A > Request B > Request C. Therefore, in the client-side request shell module, request A is encrypted and transmitted first.
[0092] The server-side encryption / decryption gateway module mainly receives encrypted request data transmitted by clients over the network, decrypts the client requests and verifies the signatures, encrypts the response data of the business server, decrypts the request data uniformly in front of the business server, encrypts the returned data, and protects the business logic from being exposed.
[0093] The specific steps for decrypting client request data are as follows:
[0094] Step D1: The server-side encryption / decryption gateway module listens on a specified network port through the gateway, receives requests sent by clients via the HTTPS protocol, and extracts encrypted data from the received requests, as shown in the following example:
[0095] Encrypted request body data (encrypted using SM4).
[0096] Digital signature (signed using an SM2 private key).
[0097] Checksum (hash value generated using SM3).
[0098] Step D2: The server-side encryption / decryption gateway module extracts the JSON format data sent by the client, uses a JSON parsing library to decode the data from the network transmission format into an operable structure, and checks whether the timestamp matches the server time to ensure the timeliness of the request and prevent attackers from gaining unauthorized access by intercepting and resending old requests.
[0099] Step D3: The server-side encryption / decryption gateway module obtains the symmetric key (SM4 session key) of the current session and uses the session key to decrypt the encrypted data using the SM4 algorithm.
[0100] Specifically, the server-side encryption / decryption gateway module dynamically generates SM4 session keys to ensure that each communication key is unique, and distributes the keys to the client through a secure channel (such as a key negotiation mechanism).
[0101] Step D4: For the decrypted plaintext data, generate a data digest using the SM3 hash algorithm, and compare the locally generated hash value with the hash field provided by the client. This ensures that the decrypted data has not been tampered with during transmission.
[0102] Step D5: Encapsulate the decrypted plaintext data according to the format required by the business server (e.g., HTTP POST request). Transmit it to the business server via a network protocol (e.g., HTTP / HTTPS).
[0103] The specific steps for the encrypted service server to respond with data are as follows:
[0104] Step F1: After receiving the response data from the business server, the server-side encryption / decryption network management module uses a symmetric encryption algorithm (such as SM4) and a session key to encrypt the response data, protecting business logic data from theft.
[0105] Step F2: Sign the encrypted response data using the private key of the SM2 algorithm to generate a digital signature, verify the authenticity of the data source, and provide data non-repudiation.
[0106] Step F3: Return the encrypted response data and digital signature to the client. After receiving the response data, the client request shell module first verifies the digital signature, then decrypts the response body content using a symmetric key (such as SM4), and finally verifies the integrity of the data based on the hash value.
[0107] To ensure the security of requested data and prevent unauthorized requests or malicious data from entering, a filter plugin is designed in the server-side encryption / decryption gateway module. By performing multiple checks on the requested data, the plugin verifies whether it complies with encryption and security standards, blocks non-compliant requests, and thus improves the system's defense capabilities.
[0108] Specifically, upon receiving a request, the filter plugin first checks the encryption of the request data to confirm that it has been processed using the correct encryption algorithm (such as SM4). Next, it checks the digital signature in the request to ensure data integrity. If the signature is invalid, the request is rejected directly. The filter plugin extracts the timestamp from the request and compares it with the server's current time. If the timestamp is outside the valid range, it is considered a replay attack, and the filter rejects the request. The filter plugin further analyzes the source IP address and frequency of the request. If abnormal behavior is detected (such as frequent requests from the same IP address), a restriction or warning mechanism is triggered to prevent denial-of-service (DDoS) attacks. When the request data passes all verifications, the filter plugin allows the request to continue to the backend service; otherwise, it rejects the request and logs the exception information.
[0109] It is important to note that key management is crucial in encrypted communication and data protection. Whether using symmetric encryption (such as SM4) or asymmetric encryption (such as SM2), the security of the key directly determines the security of the encryption system. If a key is leaked or used for an extended period without being updated, attackers can obtain the key by analyzing encrypted data or using brute-force attacks, leading to a decline in the security of the entire system.
[0110] In this embodiment, a dynamic key management and key rotation mechanism is designed in the key management module: keys are automatically generated, distributed, used, and updated according to requirements to ensure that an independent key is used for each communication and the key usage strategy can be flexibly adjusted; keys are changed periodically or under specific conditions during the key lifecycle, thereby reducing the risk of key leakage and cracking.
[0111] Specifically, the key generation process is as follows:
[0112] The key management module uses a hardware random number generator (e.g., utilizing hardware noise or radioactive decay) to collect unpredictable physical signals, ensuring that the generated random numbers are unpredictable by algorithms and possess high randomness. Keys are generated using either SM4 (symmetric encryption) or SM2 (elliptic curve cryptography) standards. SM4 key generation uses 128-bit random numbers as input to ensure key security; SM2 uses elliptic curves to generate public-private key pairs, providing strong resistance to cracking. The key is hashed using a hash algorithm (e.g., SHA256) to generate a unique hash value, which is then compared to hash values already stored in the database. If they match, it indicates a duplicate key. For example, the server generates an SM4 key K1K_1K1 for encrypting transfer data and simultaneously generates an SM2 key pair for secure key distribution.
[0113] The key distribution process is as follows:
[0114] The key management module encrypts the key using the public key of the SM2 asymmetric encryption algorithm, ensuring that only the client holding the corresponding private key can decrypt and obtain the key. A timestamp T1 is generated using the system time and appended to the encrypted key to ensure its validity for a specified period. The key management module compares the time requested by the recipient with the timestamp to prevent key expiration or replay attacks. TLS encryption and HTTPS secure transmission protocols ensure that the key is not stolen or tampered with during transmission. For example, the server establishes an encrypted communication channel via TLS, encrypts an SM4 key K1 using the client's SM2 public key, appends a timestamp T1, and sends it to the client. The client decrypts the key using its private key and verifies the timestamp.
[0115] The key usage process is as follows:
[0116] The key management module stores keys in a protected memory area, using memory protection mechanisms to prevent access by other processes. Simultaneously, physical protection is provided through the HSM hardware security module, ensuring that keys never leave the module in plaintext. Furthermore, the client only loads the key when needed and immediately cleans it up after use, preventing keys from remaining in memory for extended periods. SM4 employs a symmetric encryption algorithm, encrypting or decrypting data using the key. For example, the client uses the distributed key K1 to encrypt transfer data, generating encrypted data Data_Enc, and sends it to the server. Upon receiving Data_Enc, the server loads key K1 and decrypts it to obtain the plaintext Data.
[0117] The key rotation and update process is as follows:
[0118] The key management module is designed with a key lifecycle management mechanism, a security event detection and response mechanism, a distribution mechanism and a rollback mechanism, and triggers key updates periodically or based on abnormal events to reduce the security risks caused by long-term key use.
[0119] Specifically, the key lifecycle management mechanism involves setting a key's validity period or usage count, automatically triggering a key update after reaching a set threshold. For example, the key is automatically updated every 24 hours, with the system generating a new key K2 to replace it.
[0120] Security incident detection and response mechanism: The system security status is monitored in real time through log auditing, abnormal traffic analysis, and other methods. When an anomaly is detected (such as a brute-force attack attempt or data leakage), a key update is triggered. For example, upon detecting a brute-force attack, a new key K2 is immediately generated, and the client is notified to change the key.
[0121] Distribution and rollback mechanisms: New keys are transmitted encryptively, ensuring consistency during the key update process. If a failure occurs, the system rolls back to the previous valid key. For example, after detecting a leak of key K1, the server generates and distributes a new key K2. The client updates its key and notifies the server to confirm the change is complete.
[0122] This invention also relates to a request shell encryption method for a B / S architecture system based on Chinese national cryptographic algorithms. It includes:
[0123] Step 1: Encrypt the request body using the SM4 algorithm, generate a hash value using SM3 to verify data integrity, and use SM2 to sign to ensure the data source is trustworthy.
[0124] Step 2: Score the requested data based on its sensitivity and timeliness, calculate priority values, and ensure that sensitive and urgent requests are encrypted and transmitted first.
[0125] Step 3: Decrypt and verify the data integrity using SM4, then encrypt the response data using SM4 and sign it using SM2 to ensure the data is returned securely.
[0126] Step 4: Design a dynamic key management and key rotation mechanism: automatically generate, distribute, use and update keys according to needs, ensure that an independent key is used for each communication, and flexibly adjust the key usage strategy; change keys periodically or under specific conditions during the key lifecycle.
[0127] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.
[0128] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product.
[0129] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and inventive constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0130] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.
[0131] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
[0132] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. A request shell encryption system for a B / S architecture system based on national cryptographic algorithms, characterized in that, include: The module consists of a client request shell module, a server encryption / decryption gateway module, a key management module, a data storage module, and signal connections between these modules. The client-side request shell module primarily encrypts the user request body using SM4, decrypts the encrypted response body returned by the server, generates a signature for the request data, and sends the encrypted request data to the server-side encryption / decryption gateway module. It also scores the request data based on its sensitivity and timeliness, calculates priority values, and ensures that sensitive and urgent requests are encrypted and transmitted first. Furthermore, it grades the sensitivity score M of the request data according to thresholds Ym1, Ym2, and Ym3, and the timeliness score SX according to thresholds Yt1, Yt2, and Yt3; calculates the request data priority value YXZ; and sorts the request data according to these priority values, ensuring that higher-priority requests are encrypted and transmitted first. The server-side encryption / decryption gateway module is mainly used to receive encrypted request data transmitted by clients over the network, decrypt the requests, and verify the signatures. It is also responsible for uniformly encrypting the response data from the business servers. A filter plugin is designed and includes the following steps: before a request enters the backend service, the following are executed sequentially: checking the encryption of the request data; verifying the digital signature in the request, rejecting the request if the signature is invalid; extracting the timestamp from the request and comparing it with the server's current time to determine if it exceeds the valid range, thus rejecting replay requests; analyzing the request's source IP address and request frequency to detect abnormal behavior and trigger restriction or warning mechanisms; and rejecting requests that fail any verification and recording the abnormal information. The key management module is mainly used to implement dynamic key management and key rotation mechanisms, including: Key generation: The key management module generates session keys by collecting unpredictable physical signals through a hardware random number generator; the generated key is hashed using a hash algorithm to obtain a unique hash value, which is then compared with the hash value stored in the database to verify the uniqueness of the key. Key distribution: The key management module encrypts the session key using the public key of the SM2 asymmetric encryption algorithm, generates a timestamp T1, and appends it to the encryption key; the key management module compares the time requested by the receiver with the timestamp T1; and transmits the encryption key using the TLS encryption protocol and the HTTPS secure transmission protocol. Key usage and storage: The key management module stores the session key in a protected memory area and provides physical protection through the HSM hardware security module; the client only loads the session key when needed and clears it immediately after use; Key rotation and update: The key management module sets up a key lifecycle management mechanism, which automatically triggers key updates when the key validity period or number of uses is reached by setting a threshold; it also monitors the system security status in real time through log auditing and abnormal traffic analysis, and triggers key updates when an anomaly is detected; the new key is encrypted and transmitted during the key update process, and if the distribution fails, it rolls back to the previous valid key; The data storage module is used to store all data processed by each module.
2. The request shell encryption system for a B / S architecture system based on national cryptographic algorithms according to claim 1, characterized in that: In the client-side request shell module, the browser plugin intercepts HTTP requests via the WebExtension API and uses the webRequest API to listen for and modify request data; the mobile SDK intercepts network requests within the WebView and intercepts and rewrites XMLHttpRequest or fetch within the WebView component. The steps to encrypt and decrypt the request body data using the SM4 algorithm are as follows: Step S1: Serialize the request data into JSON format; Step S2: Encrypt the data using a symmetric key; Step S3: Generate an integrity verification code for the encrypted data; Step S4: Sign the request data using the SM2 private key and append it to the request header; Step S5: After receiving the encrypted data returned by the server, use SM4 to decrypt the response body and verify the integrity check code.
3. The request shell encryption system for a B / S architecture system based on national cryptographic algorithms according to claim 2, characterized in that: According to claim 1, Qm and Qsx are configurable weight parameters, and the thresholds Ym1, Ym2, Ym3, Yt1, Yt2, and Yt3 are preset thresholds.
4. The request shell encryption system for a B / S architecture system based on national cryptographic algorithms according to claim 3, characterized in that; The steps to decrypt client request data are as follows: Step D1: The server-side encryption / decryption gateway module listens on the network port through the gateway, receives requests sent by the client via the HTTPS protocol, and extracts encrypted data from the received requests; Step D2: The server-side encryption / decryption gateway module extracts the JSON format data sent by the client, uses a JSON parsing library to decode the data from the network transmission format into an operable structure, and checks whether the timestamp matches the server time; Step D3: The server-side encryption / decryption gateway module obtains the symmetric key for the current session and uses the session key to decrypt the encrypted data using the SM4 algorithm; Step D4: For the decrypted plaintext data, use the SM3 hash algorithm to generate a data digest, and compare the locally generated hash value with the hash field provided by the client; Step D5: Encapsulate the decrypted plaintext data according to an HTTP POST request; and transmit it to the business server via the HTTP / HTTPS network protocol; The steps for the encrypted service server to respond with data are as follows: Step F1: After receiving the response data from the business server, the server-side encryption / decryption network management module uses a symmetric encryption algorithm and the session key to encrypt the response data. Step F2: Sign the encrypted response data using the private key of the SM2 algorithm to generate a digital signature. Step F3: After receiving the encrypted response data and digital signature, the client request shell module first verifies the digital signature, then decrypts the response body content using the symmetric key, and finally verifies the integrity of the data based on the hash value.
5. A request shell encryption system for a B / S architecture system based on national cryptographic algorithms according to claim 4, characterized in that: According to claim 1, the abnormal information recorded by the filter plugin when rejecting a request includes at least: IP address, timestamp, signature verification result, and request frequency statistics.
6. A request shell encryption system for a B / S architecture system based on national cryptographic algorithms according to claim 5, characterized in that: The key generation process is as follows: The key management module's hardware random number generator collects unpredictable physical signals, generates keys using the SM4 or SM2 standard, performs hash operations on the keys using a hash algorithm to generate unique hash values, and compares them with the hash values already stored in the database. The key distribution process is as follows: The key management module uses the public key of the SM2 asymmetric encryption algorithm to encrypt the key, generate a timestamp T1, and append it to the encryption key. The key management module compares the time requested by the receiver with the timestamp. Use TLS encryption and HTTPS secure transport protocols to transmit keys; The key usage process is as follows: The key management module stores the key in a protected memory area and uses a memory protection mechanism to prevent other processes from accessing it; physical protection is provided by the HSM hardware security module. Meanwhile, the client only loads the key when needed and cleans it up immediately after use. SM4 uses a symmetric encryption algorithm to encrypt or decrypt data using the key. The key management module is designed with a key lifecycle management mechanism, a security event detection and response mechanism, a distribution mechanism, and a rollback mechanism. Key lifecycle management mechanism: By setting the validity period or number of uses of a key, the key will be automatically updated after the set threshold is reached; Security incident detection and response mechanism: The system security status is monitored in real time through log auditing and abnormal traffic analysis, and key updates are triggered when an anomaly is detected; Distribution and rollback mechanisms: The new key is transmitted in encrypted form, and if the transmission fails, it is rolled back to the previous valid key.
7. A request shell encryption method for a B / S architecture system based on national cryptographic algorithms, characterized in that: Step 1: Encrypt the user request body using SM4, decrypt the encrypted response body returned by the server, generate a signature for the request data, and send the encrypted request data to the server-side encryption / decryption gateway module. The module also scores the request data based on its sensitivity and timeliness, calculates priority values, and ensures that sensitive and urgent requests are encrypted and transmitted first. Furthermore, it grades the sensitivity score M of the request data according to thresholds Ym1, Ym2, and Ym3, and the timeliness score SX of the request data according to thresholds Yt1, Yt2, and Yt3; and calculates the request data priority value YXZ. Based on these priority values, the request data is sorted, with higher-priority requests being encrypted and transmitted first. Step 2: Receive encrypted request data transmitted from the client over the network, decrypt the request and verify the signature. It is also responsible for uniformly encrypting the response data from the business server, and designing a filter plugin. This filter plugin is used to sequentially execute the following before the request enters the backend service: check the encryption status of the request data; verify the digital signature in the request, rejecting the request if the signature is invalid; extract the timestamp from the request and compare it with the server's current time to determine if it exceeds the valid range, thus rejecting replay requests; analyze the request source IP address and request frequency to detect abnormal behavior and trigger restriction or warning mechanisms. Requests that fail any authentication are rejected and exception information is logged; Step 3: This step is used to implement dynamic key management and key rotation mechanisms, including: Key generation: The key management module generates session keys by collecting unpredictable physical signals through a hardware random number generator; the generated key is hashed using a hash algorithm to obtain a unique hash value, which is then compared with the hash value stored in the database to verify the uniqueness of the key. Key distribution: The key management module encrypts the session key using the public key of the SM2 asymmetric encryption algorithm, generates a timestamp T1, and appends it to the encryption key; the key management module compares the time requested by the receiver with the timestamp T1; and transmits the encryption key using the TLS encryption protocol and the HTTPS secure transmission protocol. Key usage and storage: The key management module stores the session key in a protected memory area and provides physical protection through the HSM hardware security module; the client only loads the session key when needed and clears it immediately after use; Key rotation and update: The key management module sets up a key lifecycle management mechanism, which automatically triggers key updates when the key validity period or number of uses is reached by setting a threshold; it also monitors the system security status in real time through log auditing and abnormal traffic analysis, and triggers key updates when an anomaly is detected; the new key is transmitted in encrypted form during the key update process, and if the distribution fails, it rolls back to the previous valid key.