BS architecture system request shell encryption method and system based on national cryptographic algorithm

Abstract

The invention discloses a BS architecture system request shell encryption method and system based on a national cryptographic algorithm, relates to the technical field of data encryption and decryption, and is used for solving the problem that data transmission security and efficiency are not ideal. Comprising a client request shell module, a server encryption and decryption gateway module, a key management module and a data storage module which are in signal connection. And the client request shell module encrypts the request data and verifies the data integrity. And the server encryption and decryption gateway module receives the encryption request, decrypts the encryption request and verifies the data integrity. And the key management module adopts a dynamic key generation and rotation mechanism to periodically update a key so as to improve the system security. The priority is set according to the sensitivity and timeliness of the request, and important data is ensured to be encrypted and transmitted preferentially. According to the invention, an efficient and safe data transmission scheme is provided by comprehensively applying a national cryptographic algorithm and a priority processing mechanism, and the method is widely applied to high-sensitivity data processing scenes such as finance and government affairs.

Description

Technical Field

[0001] The present invention relates to the technical field of data encryption and decryption, and more specifically, to a BS architecture system request shell encryption method and system based on a national secret algorithm. Background Art

[0002] In the current field of information security, with the widespread popularity of Internet applications, the problem of data transmission security has become increasingly prominent. Traditional encryption technology is often difficult to effectively prevent data leakage, tampering and replay attacks when facing complex network attacks. Especially in the processing of sensitive data (such as finance, medical care, government affairs and other fields), how to ensure the confidentiality, integrity and authentication of data during transmission has become a key issue to be solved urgently. With the country's emphasis on information security, national secret algorithms (such as SM4, SM2, SM3) have gradually become the standard for domestic information protection. However, the existing encryption methods may have performance bottlenecks under high load and high traffic environments, and the support for priority processing of sensitive data and dynamic key management is not comprehensive enough. Therefore, how to improve the efficiency of the system while ensuring security has become a major challenge in current technology. In response to this problem, the present invention proposes a BS architecture system request shell encryption scheme based on the national secret algorithm, combining encryption algorithms, priority processing and dynamic key management mechanisms, aiming to provide a safer and more efficient data transmission solution.

[0003] In view of the above problems, the present invention proposes a solution. Summary of the invention

[0004] In order to overcome the above-mentioned defects of the prior art, an embodiment of the present invention provides a BS architecture system request shell encryption method and system based on a national secret algorithm to solve the problems raised in the above-mentioned background technology.

[0005] To achieve the above object, the present invention provides the following technical solutions:

[0006] In a preferred embodiment, it includes: a client request shell module, a server encryption and 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 and decryption gateway module. It also scores the request data based on its sensitivity and timeliness, calculates the priority value, and ensures that sensitive and urgent requests are encrypted and transmitted first;

[0008] The server-side encryption and decryption gateway module is mainly used to receive encrypted request data transmitted by the client through the network, decrypt the request and verify the signature. It is also responsible for uniformly encrypting the response data of the business server and designing filter plug-ins;

[0009] The key management module is mainly used to design dynamic key management and key rotation mechanisms: automatically generate, distribute, use and update keys, and regularly replace keys during the key life cycle;

[0010] The data storage module is used to store all data in the processing process of each module.

[0011] In a preferred embodiment, in the client request shell module, the browser plug-in intercepts HTTP requests through the WebExtension API and uses the webRequest API to monitor and modify request data; the mobile SDK intercepts network requests in the WebView and intercepts and rewrites XMLHttpRequest or fetch in the WebView component;

[0012] Use the SM4 algorithm to encrypt and decrypt the request body data. The steps are as follows:

[0013] Step S1: Serialize the request data into JSON format;

[0014] Step S2: Encrypt data using a symmetric key;

[0015] Step S3: Generate an integrity check code for the encrypted data;

[0016] Step S4: Use the SM2 private key to sign the request data 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 the request data into different levels according to the importance of the data content: high sensitivity; medium sensitivity; low sensitivity;

[0019] Thresholds Ym1, Ym2 and Ym3 are set. When the sensitivity score of the request data is greater than or equal to Ym1 and less than Ym2, the request data is low-sensitivity request data; when the sensitivity score of the request data is greater than or equal to Ym2 and less than Ym3, the request data is medium-sensitivity request data; when the sensitivity score of the request data is greater than or equal to Ym3, the request data is high-sensitivity request data;

[0020] The timeliness of the requested data is divided into different levels according to the response time requirements of the request: high timeliness; medium timeliness; low timeliness;

[0021] Thresholds Yt1, Yt2 and Yt3 are set. When the timeliness score of the request data is greater than or equal to Yt1 and less than Yt2, the request data is low timeliness request data; when the timeliness score of the request data is greater than or equal to Yt2 and less than Yt3, the request data is medium timeliness request data; when the timeliness score of the request data is greater than or equal to Yt3, the request data is high timeliness request data;

[0022] The client request shell module uses the weighted average sensitivity score and timeliness score of each request data to calculate the priority value 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 value 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 of decrypting the client request data are as follows:

[0024] Step D1: The server encryption and decryption gateway module receives the request sent by the client through the HTTPS protocol through the gateway monitoring network port, and extracts the encrypted data from the received request;

[0025] Step D2: The server-side encryption and decryption gateway module extracts the JSON format data sent by the client, uses the 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 and decryption gateway module obtains the symmetric key of the current session and uses the session key to decrypt the encrypted data using the SM4 algorithm;

[0027] Step D4: Use the SM3 hash algorithm to generate a data summary for the decrypted plaintext data, 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 the HTTP POST request and transmit it to the business server via the HTTP / HTTPS network protocol;

[0029] The steps to encrypt the business server response data are as follows:

[0030] Step F1: After receiving the response data from the service server, the server-side encryption and decryption network management module uses a symmetric encryption algorithm and a session key to encrypt the response data from the service server.

[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 the client request shell module receives the encrypted response data and digital signature, it first verifies the digital signature, 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, after receiving a request, the filter plug-in first checks the encryption status of the request data; then checks the digital signature in the request, and directly rejects the request if the signature is invalid; the filter plug-in extracts the timestamp in the request and compares it with the current time of the server; if the timestamp is not within the valid range, it is considered a replay attack and the filter will reject the request; the filter plug-in further analyzes the source IP address and frequency of the request, detects abnormal behavior, triggers a restriction or warning mechanism, and if the request data passes all verifications, the filter plug-in allows the request to continue to enter the backend service, otherwise the request is rejected and the abnormal information is recorded.

[0034] In a preferred embodiment, the key generation process is as follows:

[0035] The hardware random number generator of the key management module collects unpredictable physical signals, generates keys using the SM4 or SM2 standard, performs hash operations on the keys through a hash algorithm, generates a unique hash value, and compares it with the hash value 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 encrypted key. The key management module compares the time requested by the recipient with the timestamp; uses the TLS encryption protocol and the HTTPS secure transmission protocol to transmit the key;

[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. The HSM hardware security module provides physical protection. At the same time, the client only loads the key when needed and clears it immediately after use. SM4 uses a symmetric encryption algorithm to encrypt or decrypt data using a key.

[0040] The key management module designs key lifecycle management mechanism, security incident detection and response mechanism, distribution mechanism and rollback mechanism.

[0041] Key lifecycle management mechanism: By setting the validity period or number of times a key is used, key updates are automatically triggered when the set threshold is reached;

[0042] Security incident detection and response mechanism: Through log auditing and abnormal traffic analysis, the system security status is monitored in real time, and key updates are triggered when abnormalities are found;

[0043] Distribution and rollback mechanisms: Encrypt and transmit new keys, and roll back to the last valid key if it fails.

[0044] In a preferred embodiment, step 1: encrypt the request body using the SM4 algorithm, generate a hash value to verify data integrity using SM3, and use SM2 to sign to ensure that the data source is credible;

[0045] Step 2: Score the requested data based on its sensitivity and timeliness, calculate the priority value, and ensure that sensitive and urgent requests are encrypted and transmitted first;

[0046] Step 3: Use SM4 to decrypt and verify data integrity. After processing, perform SM4 encryption and SM2 signature on the response data to ensure that the data is returned safely.

[0047] Step 4: Design a dynamic key management and key rotation mechanism: automatically generate, distribute, use, and update keys to ensure that each communication uses an independent key and flexibly adjust the key usage strategy; replace keys regularly or under specific conditions during the key life cycle.

[0048] The present invention discloses a BS architecture system request shell encryption method and system based on a national secret algorithm, which relates to the technical field of data encryption and decryption, and is used to solve the problem of unsatisfactory data transmission security and efficiency; it includes: a client request shell module, a server encryption and 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 the data integrity. The server encryption and decryption gateway module receives the encryption request and verifies the data integrity after decryption. The key management module adopts a dynamic key generation and rotation mechanism to regularly update the key to improve system security. Priority is set according to the sensitivity and timeliness of the request to ensure that important data is encrypted and transmitted first. The present invention provides an efficient and secure data transmission solution by comprehensively using the national secret algorithm and the priority processing mechanism, which is widely used in highly sensitive data processing scenarios such as finance and government affairs. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Figure 1 This is a schematic diagram of the structure of a BS architecture system request shell encryption system based on a national secret algorithm of the present invention.

[0050] Figure 2 This is an operation flow chart of a BS architecture system request shell encryption method based on a national secret algorithm of the present invention. DETAILED DESCRIPTION

[0051] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0052] Embodiment: The present invention discloses a BS architecture system request shell encryption system based on a national secret algorithm, including: a client request shell module, a server encryption and decryption gateway module, a key management module and a data storage module, and signal connections between the modules.

[0053] The data storage module is used to store all data in the processing process of each module.

[0054] The client request module is mainly used to encrypt the user request body using SM4, decrypt the encrypted response body returned by the server, and generate a signature for the request data to ensure data integrity, protect the request data, prevent sensitive information from being stolen or tampered with, and send the encrypted request data to the server-side encryption and decryption gateway module.

[0055] In the client request shell module, the browser plug-in intercepts HTTP requests through the WebExtension API and uses the webRequest API to monitor and modify request data; the mobile SDK intercepts network requests in WebView and intercepts and rewrites XMLHttpRequest or fetch in the WebView component. Enhance control and ensure 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 the symmetric key (SM4).

[0059] Step S3: Generate an integrity check code (SM3 hash value) for the encrypted data.

[0060] Step S4: Use the SM2 private key to sign the request data 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] In order to optimize the efficiency and security of the system, especially in high-load and high-traffic environments, reasonable priority processing can ensure that key requests are processed in a timely and secure manner. In this embodiment, the priority of the 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 score and timeliness score of each request data through 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] Thresholds Ym1, Ym2 and Ym3 are set. When the sensitivity score of the request data is greater than or equal to Ym1 and less than Ym2, the request data is low-sensitivity request data; when the sensitivity score of the request data is greater than or equal to Ym2 and less than Ym3, the request data is medium-sensitivity request data; when the sensitivity score of the request data is greater than or equal to Ym3, the request data is high-sensitivity request data;

[0066] According to the response time requirements of the request, the timeliness of the request 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 request data is greater than or equal to Yt1 and less than Yt2, the request data is low timeliness request data; when the timeliness score of the request data is greater than or equal to Yt2 and less than Yt3, the request data is medium timeliness request data; when the timeliness score of the request data is greater than or equal to Yt3, the request data is high timeliness request data;

[0068] For example, the request data obtained by the client request shell module is as follows:

[0069] Request A:

[0070] Data content: User requests to transfer 10,000 yuan from account A to account B.

[0071] Sensitivity: High (involving user funds).

[0072] Timeliness: High (real-time processing is required).

[0073] Request B (balance inquiry request):

[0074] Data content: User wants to check account balance.

[0075] Sensitivity: Medium (concerning privacy but with low risk).

[0076] Timeliness: Medium (needs quick response but not real-time).

[0077] Request C (log upload request):

[0078] Data content: System upload operation log for background analysis.

[0079] Sensitivity: Low (no sensitive information).

[0080] Timeliness: Low (non-real-time).

[0081] The client 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 score: 6;

[0088] Request C:

[0089] Sensitivity score: 2;

[0090] Timeliness score: 2;

[0091] Furthermore, the client request shell module calculates the priority value of each request data by weighted average of the sensitivity score and timeliness score of each request data, and integrates the two dimensions of sensitivity and timeliness into one priority value through reasonable weight allocation. Specifically based on 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 value of the timeliness score of each request data, and SX represents the timeliness score of each request data. For example: by calculation, Qm is 0.7, Qsx is 0.3, and the example data is substituted into the calculation to obtain that 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. By comparing the priority values ​​of the three, the priority order is: request A> request B> request C. Therefore, request A is encrypted and transmitted first in the client request shell module.

[0092] The server-side encryption and decryption gateway module mainly receives the encrypted request data transmitted by the client through the network, decrypts the client request and verifies the signature, encrypts the response data of the business server, uniformly decrypts the request data in front of the business server, encrypts the return 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 encryption and decryption gateway module listens to the specified network port through the gateway, receives the request sent by the client through the HTTPS protocol, and extracts the encrypted data from the received request, as shown in the following example:

[0095] Encrypted request body data (encrypted using SM4).

[0096] Digital signature (signed using SM2 private key).

[0097] Checksum (hash value generated using SM3).

[0098] Step D2: The server-side encryption and decryption gateway module extracts the JSON format data sent by the client, uses the 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 intercepting and resending old requests to gain illegal access.

[0099] Step D3: The server-side encryption and 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 and 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: Use the SM3 hash algorithm to generate a data summary for the decrypted plaintext data, and compare the locally generated hash value with the hash field provided by the client to ensure that the decrypted data has not been tampered with during transmission.

[0102] Step D5: Encapsulate the decrypted plaintext data in the format required by the service server (such as HTTP POST request), and transmit it to the service server via a network protocol (such as HTTP / HTTPS).

[0103] The specific steps for encrypting the business server response data are as follows:

[0104] Step F1: After receiving the response data from the service server, the server-side encryption and decryption network management module uses a symmetric encryption algorithm (such as SM4) and a session key to encrypt the response data from the service server to protect the service logic data from being stolen.

[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, 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] Taking into account the security of request data and in order to prevent the influx of illegal requests or malicious data, a filter plug-in is designed in the server-side encryption and decryption gateway module. Through multiple checks on the request data, it is verified whether it meets the encryption and security standards, and non-compliant requests are intercepted, thereby improving the system's defense capabilities.

[0108] Specifically, after receiving the request, the filter plug-in first checks the encryption of the request data to confirm whether the data has been processed by the correct encryption algorithm (such as SM4). Then check the digital signature in the request and ensure the integrity of the data by verifying the signature. If the signature is invalid, the request is directly rejected. The filter plug-in extracts the timestamp in the request and compares it with the current time of the server. If the timestamp is not within the valid range, it is considered a replay attack and the filter will reject the request. The filter plug-in 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 will be triggered to prevent denial of service attacks (DDoS). When the request data passes all verifications, the filter plug-in allows the request to continue to enter the backend service, otherwise the request is rejected and the abnormal information is recorded.

[0109] It should be noted that key management is crucial in encrypted communications and data protection. Whether it is 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 the key is leaked or used for a long time without being updated, attackers can obtain the key by analyzing the encrypted data or using brute force, resulting in a decrease in the security of the entire system.

[0110] In the key management module of this embodiment, a dynamic key management and key rotation mechanism is designed: keys are automatically generated, distributed, used and updated according to needs, ensuring that independent keys are used for each communication, and the key usage strategy can be flexibly adjusted; keys are replaced regularly or under specific conditions during the key life cycle, thereby reducing the risk of key leakage and cracking.

[0111] Specifically, the key generation process is as follows:

[0112] The hardware random number generator of the key management module (such as using hardware noise or radioactive decay) collects unpredictable physical signals to ensure that the generated random numbers cannot be predicted by the algorithm and are highly random. Generate keys using the SM4 (symmetric encryption) or SM2 (elliptic curve encryption) standards. SM4 key generation uses 128-bit random numbers as input to ensure key security; SM2 uses elliptic curves to generate public and private key pairs, which have strong anti-cracking capabilities. The key is hashed using a hash algorithm (such as SHA256) to generate a unique hash value, which is compared with the hash value stored in the database. If the two are the same, it means that the key is duplicated. For example: the server generates an SM4 key K1K_1K1 for encrypting transfer data, and at the same time generates an SM2 key pair for secure key distribution.

[0113] The key distribution process is as follows:

[0114] The key management module uses the public key of the SM2 asymmetric encryption algorithm to encrypt the key so that only the client holding the corresponding private key can decrypt and obtain the key. The system time is used to generate the timestamp T1, which is attached to the encrypted key to ensure that the key is valid within the specified time. The key management module compares the time requested by the recipient with the timestamp to prevent the key from expiring or being attacked by replay. The TLS encryption protocol and HTTPS secure transmission protocol are used to ensure that the key is not stolen or tampered with during transmission. For example: the server establishes an encrypted communication channel through TLS, uses the client's SM2 public key to encrypt the generated SM4 key K1, attaches the timestamp T1, and sends it to the client. The client obtains the key by decrypting it with the private key and verifies the timestamp.

[0115] The key usage process is as follows:

[0116] 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. At the same time, physical protection is provided through the HSM hardware security module so that the key never leaves the module in plain text. At the same time, the client only loads the key when needed and cleans it up immediately after use to prevent the key from existing in memory for a long time. SM4 uses a symmetric encryption algorithm to encrypt or decrypt data using a key. For example: the client uses the distributed key K1 to encrypt the transfer data, generate the encrypted data Data_Enc, and send it to the server. After receiving Data_Enc, the server loads the key K1 and decrypts it to obtain the plain text Data.

[0117] The key rotation and update process is as follows:

[0118] The key management module designs the key lifecycle management mechanism, security incident detection and response mechanism, distribution mechanism and rollback mechanism, triggers key updates regularly or based on abnormal events, and reduces the security risks brought by long-term use of keys.

[0119] Specifically, the key lifecycle management mechanism: by setting the validity period or number of times the key is used, the key update is automatically triggered after reaching the set threshold. For example, the key is automatically updated every 24 hours, and the system generates a new key K2 for replacement.

[0120] Security incident detection and response mechanism: Real-time monitoring of system security status through log auditing, abnormal traffic analysis, etc. When an abnormality is found (such as brute force cracking attempts or data leakage), key updates are triggered. For example: when a brute force cracking attack is detected, a new key K2 is immediately generated and the client is notified to change the key.

[0121] Distribution and rollback mechanisms: Encrypted transmission of new keys and ensure consistency during key updates. If a failure occurs, roll back to the last valid key. For example, after detecting that key K1 is leaked, the server generates and distributes a new key K2. After the client is updated, it notifies the server to confirm that the replacement is complete.

[0122] The present invention also relates to a BS architecture system request shell encryption method based on a national secret algorithm. It includes:

[0123] Step 1: Use the SM4 algorithm to encrypt the request body, SM3 to generate a hash value to verify data integrity, and SM2 to sign to ensure that the data source is credible.

[0124] Step 2: Score the requested data based on its sensitivity and timeliness, and calculate a priority value to ensure that sensitive and urgent requests are encrypted and transmitted first.

[0125] Step 3: Use SM4 to decrypt and verify data integrity. After processing, perform SM4 encryption and SM2 signature on the response data to ensure that the data is returned safely.

[0126] Step 4: Design a dynamic key management and key rotation mechanism: automatically generate, distribute, use, and update keys as needed, ensure that each communication uses an independent key, and flexibly adjust the key usage strategy; replace keys regularly or under specific conditions during the key life cycle.

[0127] The above formulas are all dimensionless and numerical calculations. The formula is a formula for the most recent real situation obtained by collecting a large amount of data and performing software simulation. The preset parameters in the formula are set by technicians in this field according to actual conditions.

[0128] The above embodiments may be implemented in whole or in part by software, hardware, firmware or any other combination. When implemented by software, the above embodiments may be implemented in whole or in part in the form of a computer program product.

[0129] Those of ordinary skill in the art will appreciate that the modules and algorithm steps of each example 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 performed in hardware or software depends on the specific application of the technical solution and the invention constraints. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0130] In addition, each functional module in each embodiment of the present application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0131] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0132] Finally: 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 in the protection scope of the present invention.

Claims

1. A BS architecture system request shell encryption system based on the national secret algorithm, characterized in that: include: Client request shell module, server encryption and decryption gateway module, key management module, data storage module, and signal connection between modules; 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 and decryption gateway module. It also scores the request data based on its sensitivity and timeliness, calculates the priority value, and ensures that sensitive and urgent requests are encrypted and transmitted first; The server-side encryption and decryption gateway module is mainly used to receive encrypted request data transmitted by the client through the network, decrypt the request and verify the signature. It is also responsible for uniformly encrypting the response data of the business server and designing filter plug-ins; The key management module is mainly used to design dynamic key management and key rotation mechanisms: automatically generate, distribute, use and update keys, and regularly replace keys during the key life cycle; The data storage module is used to store all data in the processing process of each module.

2. According to claim 1, a BS architecture system request shell encryption system based on a national secret algorithm is characterized in that: In the client request shell module, the browser plug-in intercepts HTTP requests through the WebExtension API and uses the webRequest API to monitor and modify request data; the mobile SDK intercepts network requests in WebView and intercepts and rewrites XMLHttpRequest or fetch in the WebView component; Use the SM4 algorithm to encrypt and decrypt the request body data. The steps are as follows: Step S1: Serialize the request data into JSON format; Step S2: Encrypt data using a symmetric key; Step S3: Generate an integrity check code for the encrypted data; Step S4: Use the SM2 private key to sign the request data 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. According to claim 2, a BS architecture system request shell encryption system based on a national secret algorithm is characterized in that: The client request shell module establishes a scoring mechanism to classify the sensitivity of the request data into different levels according to the importance of the data content: high sensitivity; medium sensitivity; low sensitivity; Thresholds Ym1, Ym2 and Ym3 are set. When the sensitivity score of the request data is greater than or equal to Ym1 and less than Ym2, the request data is low-sensitivity request data; when the sensitivity score of the request data is greater than or equal to Ym2 and less than Ym3, the request data is medium-sensitivity request data; when the sensitivity score of the request data is greater than or equal to Ym3, the request data is high-sensitivity request data; The timeliness of the requested data is divided into different levels according to the response time requirements of the request: high timeliness; medium timeliness; low timeliness; Thresholds Yt1, Yt2 and Yt3 are set. When the timeliness score of the request data is greater than or equal to Yt1 and less than Yt2, the request data is low timeliness request data; when the timeliness score of the request data is greater than or equal to Yt2 and less than Yt3, the request data is medium timeliness request data; when the timeliness score of the request data is greater than or equal to Yt3, the request data is high timeliness request data; The client request shell module uses the weighted average sensitivity score and timeliness score of each request data to calculate the priority value 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 value of the timeliness score of each request data, and SX represents the timeliness score of each request data.

4. According to claim 3, a BS architecture system request shell encryption system based on a national secret algorithm is characterized in that; The steps to decrypt client request data are as follows: Step D1: The server encryption and decryption gateway module receives the request sent by the client through the HTTPS protocol through the gateway monitoring network port, and extracts the encrypted data from the received request; Step D2: The server-side encryption and decryption gateway module extracts the JSON format data sent by the client, uses the 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 and decryption gateway module obtains the symmetric key of the current session and uses the session key to decrypt the encrypted data using the SM4 algorithm; Step D4: Use the SM3 hash algorithm to generate a data summary for the decrypted plaintext data, and compare the locally generated hash value with the hash field provided by the client; Step D5: Encapsulate the decrypted plaintext data according to the HTTP POST request and transmit it to the business server via the HTTP / HTTPS network protocol; The steps to encrypt the business server response data are as follows: Step F1: After receiving the response data from the service server, the server-side encryption and decryption network management module uses a symmetric encryption algorithm and a session key to encrypt the response data from the service server. Step F2: Sign the encrypted response data using the private key of the SM2 algorithm to generate a digital signature. Step F3: After the client request shell module receives the encrypted response data and digital signature, it first verifies the digital signature, decrypts the response body content using the symmetric key, and finally verifies the integrity of the data based on the hash value.

5. According to claim 4, a BS architecture system request shell encryption system based on a national secret algorithm is characterized in that: After receiving the request, the filter plug-in first checks the encryption of the request data; then checks the digital signature in the request. If the signature is invalid, the request is directly rejected; the filter plug-in extracts the timestamp in the request and compares it with the current time of the server; if the timestamp is not within the valid range, it is considered a replay attack and the filter will reject the request; the filter plug-in further analyzes the source IP address and frequency of the request, detects abnormal behavior, and triggers a restriction or warning mechanism. If the request data passes all verifications, the filter plug-in allows the request to continue to enter the backend service, otherwise the request is rejected and the abnormal information is recorded.

6. According to claim 5, a BS architecture system request shell encryption system based on a national secret algorithm is characterized in that: The key generation process is as follows: The hardware random number generator of the key management module collects unpredictable physical signals, generates keys using the SM4 or SM2 standard, performs hash operations on the keys through a hash algorithm, generates a unique hash value, and compares it with the hash value stored in the database; The key distribution process is as follows: The key management module encrypts the 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 recipient with the timestamp; Use TLS encryption protocol and HTTPS secure transmission protocol 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. The HSM hardware security module provides physical protection. At the same time, the client only loads the key when needed and clears it immediately after use. SM4 uses a symmetric encryption algorithm to encrypt or decrypt data using a key. The key management module designs key lifecycle management mechanism, security incident detection and response mechanism, distribution mechanism and rollback mechanism. Key lifecycle management mechanism: By setting the validity period or number of times a key is used, key updates are automatically triggered when the set threshold is reached; Security incident detection and response mechanism: Through log auditing and abnormal traffic analysis, the system security status is monitored in real time, and key updates are triggered when abnormalities are found; Distribution and rollback mechanisms: Encrypt and transmit new keys, and roll back to the last valid key if it fails.

7. A BS architecture system request shell encryption method based on a national secret algorithm, characterized in that: Step 1: Use the SM4 algorithm to encrypt the request body, SM3 to generate a hash value to verify data integrity, and SM2 signature to ensure that the data source is credible; Step 2: Score the requested data based on its sensitivity and timeliness, calculate the priority value, and ensure that sensitive and urgent requests are encrypted and transmitted first; Step 3: Use SM4 to decrypt and verify data integrity. After processing, perform SM4 encryption and SM2 signature on the response data to ensure that the data is returned safely. Step 4: Design a dynamic key management and key rotation mechanism: automatically generate, distribute, use, and update keys to ensure that each communication uses an independent key and flexibly adjust the key usage strategy; replace keys regularly or under specific conditions during the key life cycle.

Images