A lightweight key service security management method
By using a lightweight cryptographic service security management method that employs consensus SM4 keys and the SM2 algorithm between business nodes and service nodes, the problems of slow communication speed and high resource consumption of the HTTPS protocol are solved, achieving data security and efficient system operation.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- GUANYUAN (SHANGHAI) TECH CO LTD
- Filing Date
- 2023-08-21
- Publication Date
- 2026-05-29
AI Technical Summary
The existing HTTPS protocol requires two encryption and decryption operations for communication between business nodes and gateways, and between gateways and service layers, which affects communication response speed, consumes high resources, and is time-consuming during the handshake phase.
A lightweight cryptographic service security management method is adopted. The public and private keys are pre-set during the initialization of business nodes and service nodes using a key management system. Data is encrypted using a consensus SM4 key, and the SM2 signature algorithm is used to ensure data integrity and the SM2 asymmetric encryption algorithm is used to ensure data confidentiality. During communication, the consensus key ID is transmitted in the HTTP request header and managed in the key management system. Key expiration is checked periodically, and multiple service nodes are uniformly scheduled by the business nodes.
It achieves the protection of data integrity and confidentiality during communication, reduces communication response time and resource consumption, reduces the computing burden on hardware devices, and improves system stability and troubleshooting efficiency.
Smart Images
Figure CN116886434B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of cryptographic service security technology, specifically a lightweight cryptographic service security management method. Background Technology
[0002] Frequent network communication exists between different subsystems, and ensuring that the true content of the data is not exposed during transmission and that the data is not tampered with is a major challenge. Business nodes and the service layer frequently interact with each other. To ensure confidentiality and integrity of the communication data between business nodes and the service layer, it is necessary to protect the confidentiality and integrity of the communication data. While the existing HTTPS protocol can achieve this, it has the following drawbacks: communication between business nodes and the gateway, and communication between the gateway and the service layer, both require encryption and decryption, which affects communication response speed. Furthermore, HTTPS connections consume significantly more server resources, and the HTTPS handshake phase is relatively time-consuming. Summary of the Invention
[0003] To address the shortcomings of existing technologies, such as the fact that while the existing HTTPS protocol can achieve security, it has the following drawbacks: communication between business nodes and gateways, as well as communication between gateways and service layers, requires encryption and decryption, which affects communication response speed. In addition, HTTPS connections consume significantly more server-side resources, and the HTTPS handshake phase is relatively time-consuming. Therefore, this invention provides a lightweight cryptographic service security management method.
[0004] To solve the above-mentioned technical problems, the present invention provides the following technical solution:
[0005] This invention provides a lightweight cryptographic service security management method, comprising a business node system, a service node system, a gateway, and a key management system; characterized by the following steps:
[0006] Step 1: When initializing the business node system and the service node system, the public key and private key are pre-configured using the key management system, where the business node system holds the public key and the service node system holds the private key.
[0007] Step 2: Before communication between the business node system and the service node system begins, identify the interfaces of the business node system and the service node system that require data protection; and add security protection labels to the interfaces that require data protection.
[0008] Step 3: When the business node system and the service node system start communicating, the business node system and the service node system reach a consensus on an SM4 key. The service node system generates a unique key ID in the key management system, signs this key ID using a pre-set private key, encrypts the communication data using the consensus SM4 key, and places the consensus key ID and the consensus key ID signature in the HTTP request header, which is then sent to the business node system along with the communication data.
[0009] Step 4: When the business node system receives the communication data, it obtains the signature value of the consensus key ID in the HTTP request header, verifies the signature using the preset public key. If the signature verification fails, it means that the key ID has been tampered with, the communication ends, and the communication result is returned to the initiator.
[0010] Step 5: After obtaining the plaintext consensus key ID, the management node system uses this ID to retrieve key data from the shared key management system of both parties, and decrypts the communication data to obtain the communication data.
[0011] Step 6: After performing actual business processing, the receiving party needs to respond to the initiating party with the communication result. First, it checks whether the current communication key has expired. If it has not expired, it directly uses the current key to encrypt the response data; if it has expired, it needs to reach a consensus on a new SM4 key to respond to the initiating party.
[0012] Step 7: If the consensus key expires, use the previous consensus key to perform HMAC calculation on the new consensus key, and send the calculation result and the new consensus key together to the other party.
[0013] As a preferred embodiment of the present invention, the business node system is used to provide users with a web page for password service business operations, as well as to generate and import certificates and generate and distribute keys, but does not directly provide password services to users. Password service-related requests submitted by users on the web page are routed to the service node through an intermediate gateway according to a certain strategy.
[0014] As a preferred embodiment of the present invention, the service node system consists of multiple service nodes forming a load balancer, used to provide the password service to the business nodes. In addition, when a user calls an HTTP interface, the call is routed through an intermediate gateway to the service node system to perform the password service calculation.
[0015] As a preferred technical solution of the present invention, the gateway is implemented through Spring Cloud Gateway to provide access points for all API interface services, manage all API services and policies in the same way, and serve as an aggregation point for all backend business services to implement security, authentication, routing, filtering and flow control policies.
[0016] As a preferred embodiment of the present invention, a heartbeat mechanism and a server resource monitoring mechanism exist between the business nodes in the business node system and the service nodes in the service node system.
[0017] The heartbeat mechanism states that each service node periodically sends heartbeat data to the business node, indicating that the service node is alive and the next encryption calculation task can be sent to that node.
[0018] If a business node does not receive heartbeat data from a service node within a certain period of time, the service node is considered abnormal. An alarm will be sent to the user via email or instant messaging software, and the status of the service node will be marked as abnormal. The next encryption calculation task will not be sent to this node.
[0019] The server resource monitoring mechanism involves service nodes periodically sending resource usage information of the server they reside on to business nodes. Business nodes need to determine whether the resource usage information of the service nodes exceeds the system configuration threshold within a certain period of time. If it does, an alarm is sent to remind the user.
[0020] The beneficial effects of this invention are:
[0021] 1. This lightweight cryptographic service security management method protects the integrity and confidentiality of data between communication systems. Integrity is primarily achieved through the SM2 signature algorithm, while confidentiality is primarily achieved through the SM2 asymmetric encryption algorithm. For both encryption algorithms, the consensus key is generated by the communication initiator and stored in a shared key management system between the two communicating parties. This system stores key IDs and periodically checks whether the keys exceed a preset key consensus period to prevent key leakage or tampering. The encryption process for data between the communication systems is uniformly completed by the service node system. To reduce the coupling between the cryptographic service and business modules, the business node is only responsible for interacting with the user, while the cryptographic computation task is completed by the service node. To reduce the hardware requirements caused by a large number of cryptographic computation tasks in a short period, the system is configured with a multi-service node function, with multiple service nodes uniformly scheduled by the business node. To quickly troubleshoot problems when the system's communication protection function malfunctions, the system stores the consensus key ID used each time and checks whether the consensus keys used by both parties in the communication system are the same after a communication failure.
[0022] 2. This lightweight cryptographic service security management method aims to establish stable connections between multiple service nodes and business nodes in the system over a long period. For each service node, a heartbeat data is sent to the business node via HTTP once every certain time period. After receiving the heartbeat data from the service node, the business node updates its liveness status. If no heartbeat data is received from a service node within the period, it indicates that the service node is abnormal. When issuing the next cryptographic calculation task, only nodes with normal service status are considered. Attached Figure Description
[0023] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention and do not constitute a limitation thereof.
[0024] In the attached diagram:
[0025] Figure 1 This is a schematic diagram of the structure of a lightweight cryptographic service security management method according to the present invention;
[0026] Figure 2 This is an overview diagram of a lightweight cryptographic service security management method according to the present invention. Detailed Implementation
[0027] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.
[0028] Example: Figure 1 , Figure 2 As shown, this invention provides a lightweight cryptographic service security management method, including a business node system, a service node system, a gateway, and a key management system; characterized by comprising the following steps:
[0029] Step 1: When initializing the business node system and the service node system, the public key and private key are pre-configured using the key management system, where the business node system holds the public key and the service node system holds the private key.
[0030] Step 2: Before communication between the business node system and the service node system begins, identify the interfaces of the business node system and the service node system that require data protection; and add security protection labels to the interfaces that require data protection.
[0031] Step 3: When the business node system and the service node system start communicating, the business node system and the service node system reach a consensus on an SM4 key. The service node system generates a unique key ID in the key management system, signs this key ID using a pre-set private key, encrypts the communication data using the consensus SM4 key, and places the consensus key ID and the consensus key ID signature in the HTTP request header, which is then sent to the business node system along with the communication data.
[0032] Step 4: When the business node system receives the communication data, it obtains the signature value of the consensus key ID in the HTTP request header, verifies the signature using the preset public key. If the signature verification fails, it means that the key ID has been tampered with, the communication ends, and the communication result is returned to the initiator.
[0033] Step 5: After obtaining the plaintext consensus key ID, the management node system uses this ID to retrieve key data from the shared key management system of both parties, and decrypts the communication data to obtain the communication data.
[0034] Step 6: After performing actual business processing, the receiving party needs to respond to the initiating party with the communication result. First, it checks whether the current communication key has expired. If it has not expired, it directly uses the current key to encrypt the response data; if it has expired, it needs to reach a consensus on a new SM4 key to respond to the initiating party.
[0035] Step 7: If the consensus key expires, use the previous consensus key to perform HMAC calculation on the new consensus key, and send the calculation result and the new consensus key together to the other party.
[0036] The communication between the business node system and the service node system is mainly achieved through RPC calls.
[0037] (1) Before the system is initialized, a pair of public and private keys need to be prepared between the business node and the service node. The service node holds the private key and the business node holds the public key.
[0038] (2) Before communication begins, the service node initiates key consensus, generates a consensus key in the key management system and holds the key ID, signs the consensus key ID with the private key, encrypts the communication data with the consensus key using SM4, puts the consensus key ID and the signature value of the consensus key ID in the HTTP request header, and sends the HTTP request.
[0039] (3) After receiving this communication request, the management node uses the public key and the consensus key ID and its signature value from the HTTP request header to verify the signature. Once verification is successful, the confidentiality and integrity of the key are ensured. The consensus key data is then retrieved from the key management system using the consensus key ID, and the communication data is decrypted, thus ending the communication.
[0040] (4) If the consensus key needs to be changed, the service node uses the previous consensus key to perform HMAC on the new consensus key and sends the HMAC result and the new consensus key ID to the service node.
[0041] SM4 was released by the State Cryptography Administration on March 21, 2012. The relevant standard is "GM / T 0002-2012 SM4 Block Cipher Algorithm (formerly SMS4 Block Cipher Algorithm)". The SM4 algorithm is a block cipher algorithm with a block length of 128 bits and a key length of 128 bits. Both the encryption and key expansion algorithms employ a 32-round nonlinear iterative structure, performing encryption operations in units of words (32 bits). Each iteration is a round of transformation function F. The SM4 encryption and decryption algorithms have the same structure, except that the round keys are reversed; the decryption round key is the reverse of the encryption round key.
[0042] SM2 is an elliptic curve public-key cryptography algorithm released by the State Cryptography Administration on December 17, 2010. The digital signature algorithm, key exchange protocol, and public-key encryption algorithm all use the SM3 cryptographic hash algorithm and random number generator approved by the State Cryptography Administration. The digital signature algorithm, key exchange protocol, and public-key encryption algorithm select finite fields and elliptic curves according to general principles to generate key pairs.
[0043] The business node system mainly provides users with web pages for password service operations, such as generating and importing certificates, generating and distributing keys, etc. Its characteristic is that it does not directly provide password services to users. Password service-related requests submitted by users on the web page will be routed to the service node through an intermediate gateway according to certain policies.
[0044] The service node system consists of multiple service nodes forming a load balancer. Its features are: firstly, it provides the cryptographic service business functions to the business nodes; secondly, users can call the HTTP interface and route through the intermediate gateway to the service node to call the cryptographic service calculation functions, such as SM4 and SM2 encryption and decryption, HMAC_SM3, signature verification, etc.
[0045] The gateway described is implemented using Spring Cloud Gateway, and its main features are: firstly, it provides an access point for all API interface services, enabling unified management of all API services and policies; secondly, as the aggregation point for all backend business services, it can implement security, authentication, routing, filtering, and flow control policies. Spring Cloud Gateway is an API gateway built on Spring Framework 5.0 and Spring Boot 2.0, designed to provide a simple and effective way to route to APIs and provide cross-cutting concerns, including security, monitoring / metrics, and resilience. As the sole entry point for accessing internal systems, in addition to providing basic internal routing functions, it also provides authentication, monitoring, load balancing, rate limiting, degradation, and authorization functions.
[0046] The key management system is responsible for key maintenance, including key storage, generation, import, and rotation.
[0047] Among them, there is a heartbeat mechanism and a server resource monitoring mechanism between the business nodes in the business node system and the service nodes in the service node system.
[0048] The heartbeat mechanism states that each service node periodically sends heartbeat data to the business node, indicating that the service node is alive and the next encryption calculation task can be sent to that node.
[0049] If a business node does not receive heartbeat data from a service node within a certain period of time, the service node is considered abnormal. An alarm will be sent to the user via email or instant messaging software, and the status of the service node will be marked as abnormal. The next encryption calculation task will not be sent to this node.
[0050] The server resource monitoring mechanism involves service nodes periodically sending resource usage information of the server they reside on to business nodes. Business nodes need to determine whether the resource usage information of the service nodes exceeds the system configuration threshold within a certain period of time. If it does, an alarm is sent to remind the user.
[0051] This invention divides a distributed cryptographic service system into several modules: business nodes, gateways, service layers, and key management systems.
[0052] This method divides user requests into two main categories: one is cryptographic service requests, which include, but are not limited to, certificate generation, import and download, key generation, update and rotation, etc.; the other is cryptographic service computation requests, which include, but are not limited to, SM2 and SM4 encryption and decryption, HMAC_SM3, signing and signature verification, etc.
[0053] Therefore, the business node itself does not have any password service functions. Password service business requests submitted by users on the web page are mainly submitted by the business node to the service node for processing.
[0054] Cryptographic service computation requests are mainly initiated by users through HTTP requests to the gateway, which then routes the requests to the service nodes for computation and processing.
[0055] This method primarily protects the integrity and confidentiality of data between communication systems. Integrity is mainly achieved through the SM2 signature algorithm, while confidentiality is mainly achieved through the SM2 asymmetric encryption algorithm.
[0056] For the two encryption algorithms, the consensus key used is generated by the communication initiator and stored in a key management system jointly managed by both parties. The system stores the key ID and periodically checks whether the key exceeds the preset key consensus period to prevent key leakage or tampering.
[0057] The encryption process for data between the communication systems is uniformly completed by the service node system. To reduce the coupling between the cryptographic service and business modules, the business node is only responsible for interacting with the user, while the cryptographic calculation task is completed by the service node. To reduce the hardware requirements caused by a large number of cryptographic calculation tasks in a short period of time, the system is equipped with a multi-service node function, and multiple service nodes are uniformly scheduled by the business node.
[0058] To ensure stable connections between multiple service nodes and business nodes over extended periods, each service node must send a heartbeat to the business node via HTTP within a certain time period. Upon receiving this heartbeat, the business node updates its liveness status. Failure to receive a heartbeat from a service node within the specified period indicates a service node service malfunction. When issuing the next password calculation task, only those with a positive service status are considered. To quickly troubleshoot issues when the system's communication protection function fails, the system stores the consensus key ID used each time. After a communication failure, the system checks the consensus key ID used by both parties in the communication system.
[0059] This method relates to a method for protecting communication data. The communication interfaces between the two systems that require communication data protection are identified by Spring annotations. Only interfaces identified by the annotations will use the above protection method for data protection.
[0060] The service system uses a consensus key to encrypt the request body of the HTTP request using SM4, and the consensus key is signed with a pre-set private key.
[0061] The business node system uses a pre-configured public key to verify the consensus key signature value in the HTTP request header. After ensuring that the consensus key has not been tampered with, it decrypts the HTTP request body to obtain the communication data. Through the above implementation process, a lightweight and secure distributed cryptographic service can be managed.
[0062] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. 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 lightweight key service security management method, comprising a business node system, a service node system, and a gateway; a key management system; characterized in that, Includes the following steps: Step 1: When initializing the business node system and the service node system, the public key and private key are pre-configured using the key management system, where the business node system holds the public key and the service node system holds the private key. Step 2: Before communication between the business node system and the service node system begins, identify the interfaces of the business node system and the service node system that require data protection; and add security protection labels to the interfaces that require data protection. Step 3: When the business node system and the service node system start communicating, the business node system and the service node system reach a consensus on an SM4 key. The service node system generates a unique key ID in the key management system, signs this key ID using a pre-set private key, encrypts the communication data using the consensus SM4 key, and places the consensus key ID and the consensus key ID signature in the HTTP request header, which is then sent to the business node system along with the communication data. Step 4: When the business node system receives the communication data, it obtains the signature value of the consensus key ID in the HTTP request header, verifies the signature using the preset public key. If the signature verification fails, it means that the key ID has been tampered with, the communication ends, and the communication result is returned to the initiator. Step 5: After obtaining the plaintext consensus key ID, the key management system uses this ID to retrieve key data from the shared key management system of both parties, and decrypts the communication data to obtain the communication data. Step 6: After performing actual business processing, the receiving party needs to respond to the initiator of the communication. First, it determines whether the current communication key has expired. If it has not expired, it directly uses the current key to encrypt the response data. If the key expires, a new SM4 key needs to be agreed upon and a new responding party needs to be reached. Step 7: If the consensus key expires, use the previous consensus key to perform HMAC calculation on the new consensus key, and send the calculation result and the new consensus key together to the other party.
2. The lightweight key service security management method according to claim 1, characterized in that, The aforementioned business node system is used to provide users with a web page for key service business operations, as well as to generate and import certificates, generate and distribute keys, but does not directly provide key services to users. Key service-related requests applied for by users on the web page are routed to the service node through an intermediate gateway according to certain policies.
3. The lightweight key service security management method according to claim 1, characterized in that, The service node system consists of multiple service nodes forming a load balancer, used to provide the key service to business nodes. In addition, when users call the HTTP interface, the call is routed through an intermediate gateway to the service node system to call the key service calculation.
4. The lightweight key service security management method according to claim 1, characterized in that, The gateway, implemented using Spring Cloud Gateway, provides an access point for all API interface services, manages all API services and policies uniformly, and serves as an aggregation point for all backend business services, implementing security, authentication, routing, filtering, and flow control policies.
5. A lightweight key service security management method according to claim 1, characterized in that, There is a heartbeat mechanism and a server resource monitoring mechanism between the business nodes in the business node system and the service nodes in the service node system. The heartbeat mechanism states that each service node periodically sends heartbeat data to the business node, indicating that the service node is alive and the next encryption calculation task can be sent to that node. If a business node does not receive heartbeat data from a service node within a certain period of time, the service node is considered abnormal. An alarm will be sent to the user via email or instant messaging software, and the status of the service node will be marked as abnormal. The next encryption calculation task will not be sent to this node. The server resource monitoring mechanism involves service nodes periodically sending resource usage information of the server they reside on to business nodes. Business nodes need to determine whether the resource usage information of the service nodes exceeds the system configuration threshold within a certain period of time. If it does, an alarm is sent to remind the user.