A protocol transmission method based on custom encryption

Abstract

The application relates to the technical field of information security, and discloses a protocol transmission method based on self-defined encryption, which comprises the following steps: obtaining business request data, field sensitive marking, device identification, request timestamp, HTTPS termination node record, service forwarding node record and key record; dividing plaintext fields and sensitive fields according to the field sensitive marking and reserving the positions of the sensitive fields; correcting the key validity period according to the node receiving time, matching the key record with the device identification and the request timestamp, and establishing the corresponding relationship between the field positions and the key identification; encrypting the sensitive fields according to the corresponding relationship, generating an encrypted data packet containing the ciphertext fields, the field positions, the key identification and the check value, and re-correcting the key validity period according to the node receiving time and completing field recovery in the decryption stage, so that the plaintext exposure after HTTPS termination is reduced, and the sensitive field ciphertext transmission integrity is improved.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and more specifically, to a protocol transmission method based on custom encryption. Background Technology

[0002] When network business systems transmit sensitive business data between front-end clients, gateway proxies, and business servers, they are usually constrained by link latency, terminal computing power, service concurrency, and compatible deployment. Existing technologies mostly use transport layer encryption protection, session state verification, field permission control, and access log auditing to protect data transmission. These methods are usually suitable for application scenarios where the transmission link boundary is stable, the service node relationship is fixed, and the request timing changes gradually.

[0003] In scenarios where business requests are terminated by a gateway proxy and encryption is terminated, and where there are latency fluctuations during cross-service node forwarding, sensitive fields will enter the plaintext processing link during request parsing and internal forwarding. At the same time, the correspondence between the key validity window and the request transmission sequence will be offset. These factors make it difficult for transport layer protection and static session verification methods to maintain the ciphertext transmission state of sensitive fields, resulting in reduced integrity of ciphertext transmission of sensitive fields. Therefore, the technical problem that needs to be solved is: how to ensure the integrity of ciphertext transmission of sensitive fields while reducing plaintext exposure after HTTPS termination and enhancing the consistency of key window binding.

[0004] In view of this, the present invention proposes a protocol transmission method based on custom encryption to solve the above problems. Summary of the Invention

[0005] To overcome the aforementioned shortcomings of the prior art, the present invention provides a protocol transmission method based on custom encryption.

[0006] To achieve the above objectives, the present invention provides the following technical solution: A protocol transmission method based on custom encryption is provided, including: Obtain business request data, field sensitivity markers, device identifiers, request timestamps, HTTPS termination node records, service forwarding node records, and key records; Based on the field sensitivity marker, plaintext fields and sensitive fields are divided, the field position of sensitive fields in the business request data is preserved, and the field value of sensitive fields is moved into the set of fields to be encrypted; The key validity period of the key record is corrected based on the node reception time in the HTTPS termination node record and the service forwarding node record. The key record that matches the device identifier and request timestamp is obtained, and the correspondence between the field position and the key identifier in the key record is established. The set of fields to be encrypted is encrypted according to the corresponding relationship, generating an encrypted data packet containing plaintext fields, field positions, ciphertext fields, key identifiers, HTTPS termination node records, service forwarding node records, and checksums; The key validity period is recalibrated based on the node's reception time. The field to be decrypted is determined by combining the field position, key identifier, and check value. The decrypted sensitive fields are then written back to the plaintext fields according to their field positions.

[0007] In some embodiments, plaintext fields and sensitive fields are distinguished based on field sensitivity markers, the field positions of sensitive fields in the business request data are preserved, and the field values ​​of sensitive fields are moved into the set of fields to be encrypted, including: Parse the request fields in the business request data, read the field name, field hierarchy path, field container identifier and field value corresponding to the request field, and write the field name and field hierarchy path into the field matching record; The field matching records are matched with the field sensitivity tags to obtain the field sensitivity tags corresponding to the requested fields, and the requested fields are divided into plaintext fields and sensitive fields according to the field sensitivity tags; Write field value placeholders based on the field container identifier corresponding to the sensitive field, and generate the field position of the sensitive field in the business request data based on the field hierarchy path, field container identifier, and field value placeholders of the sensitive field. Move the values ​​of sensitive fields into the set of fields to be encrypted, and output the plaintext field, the sensitive field, the field position of the sensitive field in the business request data, and the set of fields to be encrypted.

[0008] In some embodiments, the field position of the sensitive field in the business request data is generated based on the field hierarchy path of the sensitive field, the field container identifier, and the field value placeholder identifier, including: Read the parent field and the current field in the field hierarchy path of the sensitive field, and read the field container identifier corresponding to the sensitive field; Read the member order of the sensitive field from the field container corresponding to the field container identifier, and write the member order into the field value placeholder identifier; Combine the parent field, the current field, the field container identifier, and the field value placeholder identifier to determine the field position of the sensitive field in the business request data.

[0009] In some embodiments, the key validity period of the key record is corrected based on the node reception time in the HTTPS termination node record and the service forwarding node record to obtain a key record that matches the device identifier and the request timestamp, including: Read the HTTPS termination node identifier and HTTPS termination node reception time from the HTTPS termination node record; read the service forwarding node identifier and service forwarding node reception time from the service forwarding node record; and read the key identifier, key binding device identifier, and key validity period from the key record. A request link reception record is generated based on the request timestamp, the HTTPS termination node reception time, and the service forwarding node reception time. The request link reception record is then associated with a key record whose key binding device identifier is equal to the device identifier. The key validity period of the corrected key record is obtained by correcting the key record based on the node reception time in the request link reception record, and the key record that matches the device identifier and request timestamp is extracted from the corrected key record.

[0010] In some embodiments, a request link reception record is generated based on the request timestamp, the HTTPS termination node reception time, and the service forwarding node reception time, including: Read the request timestamp, the HTTPS termination node reception time, and the service forwarding node reception time, and arrange the request timestamp, the HTTPS termination node reception time, and the service forwarding node reception time in order of receipt. The first link interval is generated based on the HTTPS termination node reception time and the request timestamp, and the second link interval is generated based on the service forwarding node reception time and the HTTPS termination node reception time. Write the forwarding relationship between the first link interval and the second link interval according to the HTTPS termination node identifier and the service forwarding node identifier into the node interval record; Write the request timestamp, the HTTPS termination node reception time, the service forwarding node reception time, and the node interval record into the same link record to obtain the request link reception record.

[0011] In some embodiments, writing the first link interval and the second link interval into the node interval record according to the forwarding relationship of the HTTPS termination node identifier and the service forwarding node identifier includes: Read the forwarding relationship between the HTTPS termination node identifier and the service forwarding node identifier, and write the HTTPS termination node identifier and the service forwarding node identifier into the node identifier record; Write the first link interval into the receiving segment between the request timestamp and the HTTPS termination node identifier, and write the second link interval into the receiving segment between the HTTPS termination node identifier and the service forwarding node identifier. Write the node identifier record, the first link interval, the second link interval, and the corresponding received segment into the same record to obtain the node interval record.

[0012] In some embodiments, establishing the correspondence between field locations and key identifiers in the key record includes: Read the field hierarchy path and field container identifier corresponding to the field location, and read the key identifier in the key record that matches the device identifier and request timestamp; Field positions are assigned to the corresponding field containers according to the field container identifier, and field positions in the same field container are associated with the same key identifier; Write the field hierarchy path, field container identifier, field position, and key identifier into the same corresponding record to obtain the correspondence between the field position and the key identifier in the key record.

[0013] In some embodiments, the set of fields to be encrypted is encrypted according to the correspondence relationship to generate an encrypted data packet containing plaintext fields, field positions, ciphertext fields, key identifiers, HTTPS termination node records, service forwarding node records, and checksums, including: Read the field values ​​from the set of fields to be encrypted, and read the field position and key identifier corresponding to the field value according to the correspondence; Extract the encryption key from the key record according to the key identifier, and use the encryption key to encrypt the field value to obtain the ciphertext field corresponding to the field position; The verification value is generated according to the order of plaintext fields, field positions, ciphertext fields, key identifiers, HTTPS termination node records, and service forwarding node records in the encrypted data packet, and then encapsulated into an encrypted data packet containing plaintext fields, field positions, ciphertext fields, key identifiers, HTTPS termination node records, service forwarding node records, and the verification value.

[0014] In some embodiments, the key validity period is recalibrated based on the node reception time, and the field to be decrypted is determined by combining the field location, key identifier, and check value, including: Read the field positions, ciphertext fields, key identifiers, and checksums from the encrypted data packets, and read the node reception times from the HTTPS termination node record and service forwarding node record in the encrypted data packets; The key validity period of the key record is recalibrated according to the node's reception time, and the decryption key record corresponding to the key identifier is read from the key record after the key validity period is recalibrated. The checksum is regenerated according to the field position, ciphertext field, and key identifier. When the regenerated checksum is the same as the checksum in the encrypted data packet, the ciphertext field is used as the field to be decrypted to determine the field to be decrypted.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention acquires business request data, field sensitivity markers, device identifiers, request timestamps, HTTPS termination node records, service forwarding node records, and key records. It then divides plaintext fields and sensitive fields based on the field sensitivity markers, allowing sensitive fields to be extracted independently from the original business request data. Next, it corrects the key validity period of the key record based on the node reception time in the HTTPS termination node record and service forwarding node record, ensuring the key status matches the device identifier and request timestamp, and establishing a correspondence between field positions and key identifiers. Subsequently, it encrypts the set of fields to be encrypted according to this correspondence, generating an encrypted data packet containing field positions, ciphertext fields, key identifiers, and checksums, ensuring sensitive fields remain in ciphertext transmission during HTTPS termination and service forwarding. During the decryption phase, it re-corrects the key validity period based on the node reception time and, combined with the field positions, key identifiers, and checksums, determines the fields to be decrypted. The decrypted sensitive fields are then written back according to their positions, thereby reducing the risk of plaintext exposure after HTTPS termination and improving the integrity of ciphertext transmission of sensitive fields. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating a protocol transmission method based on custom encryption in this invention. Figure 2 This is a flowchart illustrating the key validity period correction and matching method in this invention. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to specific embodiments and the accompanying drawings. In the following detailed description, many specific details are set forth to provide a thorough understanding of the exemplary embodiments described. However, it will be apparent to those skilled in the art that the described embodiments may be practiced without some or all of these specific details. In other exemplary embodiments, well-known structures have not been described in detail to avoid unnecessarily obscuring the concepts of this disclosure. It should be understood that the specific embodiments described herein are merely illustrative of the present invention and are not intended to limit the present invention. Furthermore, the various aspects described in the embodiments may be combined arbitrarily without conflict.

[0018] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0019] Figure 1 This disclosure illustrates a protocol transmission method based on custom encryption, provided in at least one embodiment, comprising: S10: Obtain business request data, field sensitivity markers, device identifiers, request timestamps, HTTPS termination node records, service forwarding node records, and key records; In this embodiment, business request data refers to the data content carried by the client when initiating a business processing request to the business server. It may include user input information, business parameter information, and field content generated during business processing. Field sensitivity markers refer to information that identifies the sensitive attributes of different fields in the business request data. For example, it is used to distinguish between ordinary business fields and sensitive fields that need to be encrypted. In a network business system, business request data usually needs to pass through the client, HTTPS termination node, and service forwarding node before reaching the business server. When transmitted between different nodes, the processing status and key usage status of the business request data will be affected by changes in the node receiving time. Therefore, it is necessary to obtain both the business request data and the node records related to the transmission link at the same time.

[0020] Furthermore, the HTTPS termination node record is used to record the node information corresponding to the termination position of the HTTPS encrypted link, and the service forwarding node record is used to record the service node information passed through during the continued transmission of the business request to the business server. The node record can include the node identifier and the node reception time. By obtaining the HTTPS termination node record and the service forwarding node record, the transmission time relationship of the business request data between different processing nodes can be determined. The key record is used to record the key information used in the encryption process, including the key identifier, the key binding device identifier, and the key validity period. The device identifier is used to associate the business request data with the corresponding key record, and the request timestamp is used to describe the time information when the business request was generated.

[0021] It should be noted that this embodiment does not encrypt the business request data itself, but simultaneously obtains the field information, device information, time information and transmission node information corresponding to the business request data, so that the subsequent sensitive field processing, key validity period correction and encrypted data packet generation processes can be associated based on the same request link, thereby providing a data foundation for field-level encryption and key matching in subsequent steps.

[0022] S20: Based on the field sensitivity marker, plaintext fields and sensitive fields are divided, the field position of sensitive fields in the business request data is preserved, and the field value of sensitive fields is moved into the set of fields to be encrypted; Based on field sensitivity markers, plaintext fields and sensitive fields are separated. The field positions of sensitive fields in the business request data are preserved, and the field values ​​of sensitive fields are moved into the set of fields to be encrypted, including: Parse the request fields in the business request data, read the field name, field hierarchy path, field container identifier and field value corresponding to the request field, and write the field name and field hierarchy path into the field matching record; The field matching records are matched with the field sensitivity tags to obtain the field sensitivity tags corresponding to the requested fields, and the requested fields are divided into plaintext fields and sensitive fields according to the field sensitivity tags; Write field value placeholders based on the field container identifier corresponding to the sensitive field, and generate the field position of the sensitive field in the business request data based on the field hierarchy path, field container identifier, and field value placeholders of the sensitive field. Move the values ​​of sensitive fields into the set of fields to be encrypted, and output the plaintext field, the sensitive field, the field position of the sensitive field in the business request data, and the set of fields to be encrypted.

[0023] In this embodiment, the field hierarchy path refers to the hierarchical relationship information of the request field in the business request data. For example, when the business request data is stored in a nested structure, the field hierarchy path can represent the data level where the field is located and the inclusion relationship between fields. The field container identifier refers to the information used to distinguish the data container to which the field belongs, such as the object container corresponding to an object type field or the array container corresponding to an array type field. By obtaining the field name, field hierarchy path, field container identifier and field value, the field association relationship in the original structure of the business request data can be preserved.

[0024] Understandably, by using field sensitivity markers to divide different fields in business request data, fields that do not need to be encrypted are retained as plaintext fields, while fields that need to be protected are treated as sensitive fields. This allows the business request data to maintain its original field structure, while the field values ​​of sensitive fields are moved separately into the set of fields to be encrypted.

[0025] Furthermore, after separating plaintext fields and sensitive fields, the positional relationship of sensitive fields in the original business request data is not directly deleted. Instead, the field position of sensitive fields in the business request data is generated based on the field hierarchy path, field container identifier, and field value placeholder identifier corresponding to the sensitive field. The field position is used to describe the positioning relationship of sensitive fields in the original business request structure, so that the subsequently decrypted sensitive fields can be re-associated with the corresponding business field positions.

[0026] The location of the sensitive field in the business request data is generated based on the field hierarchy path, field container identifier, and field value placeholder identifier of the sensitive field, including: Read the parent field and the current field in the field hierarchy path of the sensitive field, and read the field container identifier corresponding to the sensitive field; Read the member order of the sensitive field from the field container corresponding to the field container identifier, and write the member order into the field value placeholder identifier; Combine the parent field, the current field, the field container identifier, and the field value placeholder identifier to determine the field position of the sensitive field in the business request data.

[0027] In this embodiment, the parent field refers to the field corresponding to the upper-level data object of the sensitive field, the current field refers to the field corresponding to the sensitive field itself, the field container identifier refers to the identifier information of the field container to which the sensitive field belongs, and the field value placeholder identifier refers to the placeholder information retained in the original business request data after the field value of the sensitive field is moved into the set of fields to be encrypted. After the field value of the sensitive field is moved out, if only the field name is retained, the business server will find it difficult to determine which level or member position the sensitive field should be written back to after decryption. Therefore, it is necessary to combine the parent field, the current field, the field container identifier, and the field value placeholder identifier to jointly determine the field position.

[0028] Furthermore, when the field container corresponding to the field container identifier is an array container, the member order is used to distinguish the specific position of the same field name in different array members. When the field container corresponding to the field container identifier is an object container, the parent field and the current field are used to maintain the hierarchical correspondence between object fields. For example, the business request data includes a user list field, under which there are multiple user objects. Each user object includes an ID number field. The current field of the ID number field is the same, but the member order of different user objects in the field container is different. By writing the member order into the field value placeholder identifier, the position of the ID number field in different user objects can be distinguished.

[0029] It should be noted that combining the parent field, the current field, the field container identifier, and the field value placeholder identifier to determine the field position of the sensitive field in the business request data can preserve the structural position of the sensitive field without retaining its actual field value. This ensures that the sensitive field has the same field positioning basis in subsequent encrypted transmission, server-side decryption, and field write-back processes, thereby preventing the sensitive field value from becoming detached from the original business request data structure after being moved into the set of fields to be encrypted.

[0030] S30: Correct the key validity period of the key record according to the node reception time in the HTTPS termination node record and service forwarding node record, obtain the key record that matches the device identifier and request timestamp, and establish the correspondence between the field position and the key identifier in the key record; In this embodiment, the HTTPS termination node record refers to the record formed when the HTTPS transmission link of the business request data is terminated at the gateway proxy, load balancer node, or secure access node. The service forwarding node record refers to the node record formed during the forwarding of the business request data to the business server after HTTPS termination. The node reception time refers to the moment when the corresponding node receives the business request data. The key record is a record used to record the key identifier, the key binding device identifier, the key validity period, and the corresponding key content. The key validity period is used to limit the time range within which the key can participate in the encryption or decryption processing of the business request data.

[0031] It is understandable that after a business request passes through an HTTPS termination node, the transport layer encryption protection ends at the HTTPS termination node. The business request data may be parsed, routed, or written into the intermediate processing link during subsequent service forwarding. If the key is still selected solely based on the request timestamp or a fixed key validity period, the key validity period may not correspond to the actual time when the forwarding latency fluctuates. In this embodiment, the key validity period of the key record is corrected based on the node reception time in the HTTPS termination node record and the service forwarding node record, so that the available range of the key record can correspond to the actual node reception time through which the business request data passes.

[0032] Based on the node reception time in the HTTPS termination node record and service forwarding node record, the key validity period of the key record is corrected to obtain the key record that matches the device identifier and request timestamp, including: Read the HTTPS termination node identifier and HTTPS termination node reception time from the HTTPS termination node record; read the service forwarding node identifier and service forwarding node reception time from the service forwarding node record; and read the key identifier, key binding device identifier, and key validity period from the key record. A request link reception record is generated based on the request timestamp, the HTTPS termination node reception time, and the service forwarding node reception time. The request link reception record is then associated with a key record whose key binding device identifier is equal to the device identifier. The key validity period of the corrected key record is obtained by correcting the key record based on the node reception time in the request link reception record, and the key record that matches the device identifier and request timestamp is extracted from the corrected key record.

[0033] In this embodiment, the HTTPS termination node identifier is used to indicate the node where the business request data completes HTTPS termination, the service forwarding node identifier is used to indicate the nodes through which the business request data passes from the HTTPS termination node to the business server, and the key binding device identifier is used to indicate the front-end device or client device to which the key record is bound. By reading the HTTPS termination node identifier, the service forwarding node identifier, and the corresponding node reception time, the reception order and reception time of the business request data in the transmission link can be determined.

[0034] Furthermore, the request link receiving record is used to record the transmission relationship between the request timestamp, the HTTPS termination node receiving time, and the service forwarding node receiving time corresponding to the same business request data. By associating the request link receiving record with the key record whose key binding device identifier is equal to the device identifier, key records that do not belong to the current device can be excluded first, so that subsequent key validity period correction is only performed within the scope of the key record corresponding to the current device.

[0035] It should be noted that correcting the key validity period does not involve regenerating the key. Instead, it corrects the available time range of the key record in the current business request link based on the node reception time in the request link reception record. The corrected key record is then matched with the device identifier and request timestamp to obtain the key record corresponding to the current business request data. For example, after the current device initiates a business request, the business request first reaches the HTTPS termination node and is then forwarded to the business server by the service forwarding node. By correcting the key validity period through the node reception time, the selected key record can simultaneously conform to the current device, the request timestamp, and the transmission link status corresponding to the node reception time.

[0036] A request link reception record is generated based on the request timestamp, the HTTPS termination node reception time, and the service forwarding node reception time, including: Read the request timestamp, the HTTPS termination node reception time, and the service forwarding node reception time, and arrange the request timestamp, the HTTPS termination node reception time, and the service forwarding node reception time in order of receipt. The first link interval is generated based on the HTTPS termination node reception time and the request timestamp, and the second link interval is generated based on the service forwarding node reception time and the HTTPS termination node reception time. Write the forwarding relationship between the first link interval and the second link interval according to the HTTPS termination node identifier and the service forwarding node identifier into the node interval record; Write the request timestamp, the HTTPS termination node reception time, the service forwarding node reception time, and the node interval record into the same link record to obtain the request link reception record.

[0037] In this embodiment, the request timestamp is used to indicate the time when the front-end client generates business request data, the HTTPS termination node reception time is used to indicate the time when the gateway proxy, load balancer node, or security access node receives the business request data and completes the HTTPS termination process, the service forwarding node reception time is used to indicate the time when the business request data is forwarded to the back-end service node after HTTPS termination, and the request link reception record is a data record used to record the relationship between the reception times of the same business request data from the front-end client to the HTTPS termination node and then to the service forwarding node.

[0038] Furthermore, by arranging the request timestamp, the HTTPS termination node reception time, and the service forwarding node reception time according to their reception order, the temporal order of the business request data in the transmission link can be determined. The first link interval reflects the transmission time from when the business request data is sent from the front-end client to when it is received by the HTTPS termination node, and the second link interval reflects the forwarding time from when the business request data is received by the HTTPS termination node to when it is received by the service forwarding node. The above link intervals are not simply timeout judgment parameters, but are used to describe the time offset relationship between the key validity period and the actual request link.

[0039] Understandably, after HTTPS termination, business request data will move from the transport layer protection state to the internal forwarding link of the service. If the forwarding time between different service nodes changes, relying solely on the request timestamp to select the key record can easily lead to a mismatch between the key validity period and the actual service node reception time. For example, if the front-end client generates business request data at 10:00:00, the HTTPS termination node receives the business request data at 10:00:02, and the service forwarding node receives the business request data at 10:00:06, then the first link interval corresponds to the reception delay from the front-end to the HTTPS termination node, and the second link interval corresponds to the internal forwarding delay from the HTTPS termination node to the service forwarding node. After recording the above times and node intervals in the same link record, the key validity period of the key record can be corrected based on the actual reception link.

[0040] Write the forwarding relationship between the first link interval and the second link interval according to the HTTPS termination node identifier and the service forwarding node identifier into the node interval record, including: Read the forwarding relationship between the HTTPS termination node identifier and the service forwarding node identifier, and write the HTTPS termination node identifier and the service forwarding node identifier into the node identifier record; Write the first link interval into the receiving segment between the request timestamp and the HTTPS termination node identifier, and write the second link interval into the receiving segment between the HTTPS termination node identifier and the service forwarding node identifier. Write the node identifier record, the first link interval, the second link interval, and the corresponding received segment into the same record to obtain the node interval record.

[0041] In this embodiment, the node identifier record is used to record the node identifier relationship through which the service request data passes, and the receiving segment is used to represent the receiving interval between two adjacent times or adjacent nodes. For example, the receiving segment between the request timestamp and the HTTPS termination node identifier corresponds to the link part from when the front-end client sends the service request data to when the HTTPS termination node receives the service request data; the receiving segment between the HTTPS termination node identifier and the service forwarding node identifier corresponds to the part of the service link that continues to be forwarded after the service request data completes HTTPS termination.

[0042] Furthermore, the first link interval and the second link interval are written to different receiving segments, which allows the node interval record to include not only the time consumption information, but also the node link position corresponding to the time consumption information. Compared with the method of only recording the total transmission time, this embodiment can distinguish the transmission layer link time and the service forwarding link time. Thus, when correcting the key validity period later, the key record can be processed according to the different receiving segments before and after HTTPS termination.

[0043] It should be noted that writing the node identifier record, the first link interval, the second link interval, and the corresponding receiving segment into the same record enables the key validity period correction process to have both node and time sources. For example, when business request data passes through different HTTPS termination nodes or different service forwarding nodes, even if the request timestamp is the same, the node interval record can distinguish different transmission links through the HTTPS termination node identifier and the service forwarding node identifier, thus avoiding the mixing of key validity period correction results under different node links.

[0044] Establish the correspondence between field locations and key identifiers in the key record, including: Read the field hierarchy path and field container identifier corresponding to the field location, and read the key identifier in the key record that matches the device identifier and request timestamp; Field positions are assigned to the corresponding field containers according to the field container identifier, and field positions in the same field container are associated with the same key identifier; Write the field hierarchy path, field container identifier, field position, and key identifier into the same corresponding record to obtain the correspondence between the field position and the key identifier in the key record.

[0045] In this embodiment, the field hierarchy path and field container identifier come from the aforementioned sensitive field location generation process, and the key identifier comes from the key record that matches the device identifier and request timestamp. The correspondence between field location and key identifier is used to describe the association between the structural location of a certain sensitive field in the business request data and the key required for encryption. This ensures that when encrypting the set of fields to be encrypted later, a single key is not used for the entire business request data, but rather a field-level key reference relationship is established based on the field container where the sensitive field is located.

[0046] Furthermore, by assigning field positions to the corresponding field containers according to the field container identifier, sensitive fields belonging to the same object container or the same array container can maintain structural association when associating key identifiers. For example, if the business request data includes an order information field, which includes the recipient's name, recipient's phone number, and delivery address, and the recipient's phone number and delivery address are classified as sensitive fields, then according to the field container identifier corresponding to the order information, the field positions corresponding to the recipient's phone number and delivery address can be assigned to the same field container, and the field positions in the same field container can be associated with the same key identifier.

[0047] S40: Encrypt the set of fields to be encrypted according to the corresponding relationship, and generate an encrypted data packet containing plaintext fields, field positions, ciphertext fields, key identifiers, HTTPS termination node records, service forwarding node records, and checksums; In this embodiment, the correspondence refers to the correspondence between the field position and the key identifier in the key record. The set of fields to be encrypted refers to the set formed by the field values ​​of the sensitive fields. The ciphertext field refers to the field content formed by encrypting the field value with the encryption key. The plaintext field is used to retain the field content in the business request data that does not need to be encrypted. The field position is used to identify the structural position of the sensitive field in the original business request data. The ciphertext field is used to carry the encryption result corresponding to the sensitive field. The key identifier is used to indicate the key record corresponding to the ciphertext field.

[0048] Furthermore, in this embodiment, when generating encrypted data packets, the HTTPS termination node record and service forwarding node record are encapsulated together in the encrypted data packet. This allows the server to recalibrate the key validity period based on the node reception time carried in the encrypted data packet after receiving it, rather than relying solely on the server's local reception time or request timestamp. Through this encapsulation method, the node link information used during front-end encryption and the node link information used during server-side verification before decryption maintain source association.

[0049] The set of fields to be encrypted is encrypted according to the corresponding relationship, generating an encrypted data packet containing plaintext fields, field positions, ciphertext fields, key identifiers, HTTPS termination node records, service forwarding node records, and checksums, including: Read the field values ​​from the set of fields to be encrypted, and read the field position and key identifier corresponding to the field value according to the correspondence; Extract the encryption key from the key record according to the key identifier, and use the encryption key to encrypt the field value to obtain the ciphertext field corresponding to the field position; The verification value is generated according to the order of plaintext fields, field positions, ciphertext fields, key identifiers, HTTPS termination node records, and service forwarding node records in the encrypted data packet, and then encapsulated into an encrypted data packet containing plaintext fields, field positions, ciphertext fields, key identifiers, HTTPS termination node records, service forwarding node records, and the verification value.

[0050] In this embodiment, when reading the field value in the set of fields to be encrypted, the field position and key identifier corresponding to the field value are read simultaneously according to the aforementioned correspondence between field position and key identifier. This ensures that the field value, field position, and key identifier form a set of associated data before encryption. If only the field value is encrypted without simultaneously recording the field position and key identifier, the server will find it difficult to determine the field position that the decryption result should be written back after decryption, and it will also be difficult to determine the decryption key corresponding to different ciphertext fields.

[0051] Furthermore, by extracting the encryption key from the key record according to the key identifier, the field values ​​corresponding to different field positions can be encrypted according to the corresponding key record. The encryption key can be a symmetric encryption key, such as an AES key. The key identifier is used to indicate the corresponding key record in the encrypted data packet. By matching the encrypted field values ​​with the field positions, the ciphertext fields can maintain the association with the original business request data structure in the encrypted data packet.

[0052] It should be noted that the order in which the checksums are generated corresponds to the order in which they are arranged in the encrypted data packet. For example, the plaintext field is read first, followed by the field position, ciphertext field, key identifier, HTTPS termination node record, and service forwarding node record. The checksum is then generated based on this arrangement. After the encrypted data packet is received by the server, the server can regenerate the checksum in the same order and compare the regenerated checksum with the checksum in the encrypted data packet to determine whether the field position, ciphertext field, key identifier, and node record maintain the correspondence before transmission.

[0053] S50: Based on the node's reception time, the key validity period is recalibrated, and the field to be decrypted is determined by combining the field position, key identifier, and check value. The decrypted sensitive field is then written back to the plaintext field according to its field position.

[0054] In this embodiment, after receiving the encrypted data packet, the server does not directly extract the decryption key based on the key identifier for decryption. Instead, it first reads the node reception time from the HTTPS termination node record and service forwarding node record in the encrypted data packet, and recalibrates the key validity period of the key record based on the node reception time. The front end has already corrected the key validity period based on the node reception time when generating the encrypted data packet. The server's recalibration of the key validity period can verify the node record and key identifier in the encrypted data packet.

[0055] Furthermore, the field to be decrypted refers to the ciphertext field that is allowed to enter the decryption process after key validity period recalibration, field position verification, key identifier verification, and check value verification. The field position is used to determine the location of the original business request data corresponding to the ciphertext field, the key identifier is used to determine the corresponding decryption key record, and the check value is used to verify the field content and arrangement relationship in the encrypted data packet. By using the above information to jointly determine the field to be decrypted, the problem of ciphertext field mismatch caused by directly decrypting based solely on the key identifier can be avoided.

[0056] It should be noted that after decryption is completed on the server side, the decrypted sensitive fields are not appended to the business request data as independent data. Instead, they are written back to the business request structure that the plaintext fields maintain according to their field positions. For example, when the front end moves the ID number field value into the set of fields to be encrypted and retains the original structure position of the field, after the server decrypts the ciphertext field corresponding to the ID number, it can write the ID number field value back to the corresponding parent field and field container according to the field position, thereby restoring the business request data structure required for business processing.

[0057] The key validity period is recalibrated based on the node's reception time. The fields to be decrypted are determined by combining the field location, key identifier, and checksum, including: Read the field positions, ciphertext fields, key identifiers, and checksums from the encrypted data packets, and read the node reception times from the HTTPS termination node record and service forwarding node record in the encrypted data packets; The key validity period of the key record is recalibrated according to the node's reception time, and the decryption key record corresponding to the key identifier is read from the key record after the key validity period is recalibrated. The checksum is regenerated according to the field position, ciphertext field, and key identifier. When the regenerated checksum is the same as the checksum in the encrypted data packet, the ciphertext field is used as the field to be decrypted to determine the field to be decrypted.

[0058] In this embodiment, after the server reads the field position, ciphertext field, key identifier and check value in the encrypted data packet, it also reads the node reception time in the HTTPS termination node record and service forwarding node record in the encrypted data packet. This process makes the server's pre-decryption verification process correspond to the node link information used by the front end when generating the encrypted data packet, avoiding the key record not corresponding to the actual transmission link due to the server selecting the key based only on local time or a single request timestamp.

[0059] Furthermore, when recalibrating the key validity period of the key record based on the node reception time, the HTTPS termination node reception time and the service forwarding node reception time can be mapped to the key validity period of the key record in accordance with the aforementioned processing method for request link reception record and node interval record. The decryption key record corresponding to the key identifier can be read from the key record after recalibrating the key validity period. The decryption key record corresponds to the key identifier in the encrypted data packet, enabling the server to read the key content required for decryption for the corresponding ciphertext field.

[0060] Understandably, regenerating the checksum according to the field position, ciphertext field, and key identifier is to verify the correspondence between the field position, ciphertext field, and key identifier in the encrypted data packet. When the regenerated checksum is the same as the checksum in the encrypted data packet, it means that the ciphertext field, field position, and key identifier maintain the correspondence before transmission in the encrypted data packet. The server will then treat the ciphertext field as the field to be decrypted, and subsequent decryption processing can be performed based on the confirmed field position and decryption key record, so that the decrypted sensitive field can be written back to the plaintext field according to the field position.

[0061] The detailed description above, in conjunction with the accompanying drawings, describes examples but does not represent all examples that can be implemented or fall within the scope of the claims. The terms “example” and “exemplary” are used in this specification to mean “serving as an example, instance or illustration” and do not mean “superior to or better than other examples”.

[0062] Throughout this specification, the phrase "an embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment of the invention. Therefore, the use of these phrases may refer to more than one embodiment. Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0063] It should also be noted that these embodiments may be described as processes depicted as flowcharts, structural diagrams, or block diagrams. Although a flowchart may describe the operations as sequential processes, many of these operations can be performed in parallel or concurrently, and the order of these operations may be rearranged.

Claims

1. A protocol transmission method based on custom encryption, characterized in that, include: Obtain business request data, field sensitivity markers, device identifiers, request timestamps, HTTPS termination node records, service forwarding node records, and key records; Based on the field sensitivity marker, plaintext fields and sensitive fields are divided, the field position of sensitive fields in the business request data is preserved, and the field value of sensitive fields is moved into the set of fields to be encrypted; The key validity period of the key record is corrected based on the node reception time in the HTTPS termination node record and the service forwarding node record. The key record that matches the device identifier and request timestamp is obtained, and the correspondence between the field position and the key identifier in the key record is established. The set of fields to be encrypted is encrypted according to the corresponding relationship, generating an encrypted data packet containing plaintext fields, field positions, ciphertext fields, key identifiers, HTTPS termination node records, service forwarding node records, and checksums; Based on the node's reception time, the key validity period is recalibrated, and the field to be decrypted is determined by combining the field position, key identifier, and check value. The decrypted sensitive fields are then written back to the plaintext fields according to their field positions. Based on the node reception time in the HTTPS termination node record and service forwarding node record, the key validity period of the key record is corrected to obtain the key record that matches the device identifier and request timestamp, including: Read the HTTPS termination node identifier and HTTPS termination node reception time from the HTTPS termination node record; read the service forwarding node identifier and service forwarding node reception time from the service forwarding node record; and read the key identifier, key binding device identifier, and key validity period from the key record. A request link reception record is generated based on the request timestamp, the HTTPS termination node reception time, and the service forwarding node reception time. The request link reception record is then associated with a key record whose key binding device identifier is equal to the device identifier. The key validity period of the corrected key record is obtained by correcting the key record based on the node reception time in the request link reception record, and the key record matching the device identifier and request timestamp is extracted from the corrected key record. A request link reception record is generated based on the request timestamp, the HTTPS termination node reception time, and the service forwarding node reception time, including: Read the request timestamp, the HTTPS termination node reception time, and the service forwarding node reception time, and arrange the request timestamp, the HTTPS termination node reception time, and the service forwarding node reception time in order of receipt. The first link interval is generated based on the HTTPS termination node reception time and the request timestamp, and the second link interval is generated based on the service forwarding node reception time and the HTTPS termination node reception time. Write the forwarding relationship between the first link interval and the second link interval according to the HTTPS termination node identifier and the service forwarding node identifier into the node interval record; Write the request timestamp, the HTTPS termination node reception time, the service forwarding node reception time, and the node interval record into the same link record to obtain the request link reception record; Establish the correspondence between field locations and key identifiers in the key record, including: Read the field hierarchy path and field container identifier corresponding to the field location, and read the key identifier in the key record that matches the device identifier and request timestamp; Field positions are assigned to the corresponding field containers according to the field container identifier, and field positions in the same field container are associated with the same key identifier; Write the field hierarchy path, field container identifier, field position, and key identifier into the same corresponding record to obtain the correspondence between the field position and the key identifier in the key record.

2. The protocol transmission method based on custom encryption according to claim 1, characterized in that, Based on field sensitivity markers, plaintext fields and sensitive fields are separated. The field positions of sensitive fields in the business request data are preserved, and the field values ​​of sensitive fields are moved into the set of fields to be encrypted, including: Parse the request fields in the business request data, read the field name, field hierarchy path, field container identifier and field value corresponding to the request field, and write the field name and field hierarchy path into the field matching record; The field matching records are matched with the field sensitivity tags to obtain the field sensitivity tags corresponding to the requested fields, and the requested fields are divided into plaintext fields and sensitive fields according to the field sensitivity tags; Write field value placeholders based on the field container identifier corresponding to the sensitive field, and generate the field position of the sensitive field in the business request data based on the field hierarchy path, field container identifier, and field value placeholders of the sensitive field. Move the values ​​of sensitive fields into the set of fields to be encrypted, and output the plaintext field, the sensitive field, the field position of the sensitive field in the business request data, and the set of fields to be encrypted.

3. The protocol transmission method based on custom encryption according to claim 2, characterized in that, The location of the sensitive field in the business request data is generated based on the field hierarchy path, field container identifier, and field value placeholder identifier of the sensitive field, including: Read the parent field and the current field in the field hierarchy path of the sensitive field, and read the field container identifier corresponding to the sensitive field; Read the member order of the sensitive field from the field container corresponding to the field container identifier, and write the member order into the field value placeholder identifier; Combine the parent field, the current field, the field container identifier, and the field value placeholder identifier to determine the field position of the sensitive field in the business request data.

4. The protocol transmission method based on custom encryption according to claim 1, characterized in that, Write the forwarding relationship between the first link interval and the second link interval according to the HTTPS termination node identifier and the service forwarding node identifier into the node interval record, including: Read the forwarding relationship between the HTTPS termination node identifier and the service forwarding node identifier, and write the HTTPS termination node identifier and the service forwarding node identifier into the node identifier record; Write the first link interval into the receiving segment between the request timestamp and the HTTPS termination node identifier, and write the second link interval into the receiving segment between the HTTPS termination node identifier and the service forwarding node identifier. Write the node identifier record, the first link interval, the second link interval, and the corresponding received segment into the same record to obtain the node interval record.

5. The protocol transmission method based on custom encryption according to claim 1, characterized in that, The set of fields to be encrypted is encrypted according to the corresponding relationship, generating an encrypted data packet containing plaintext fields, field positions, ciphertext fields, key identifiers, HTTPS termination node records, service forwarding node records, and checksums, including: Read the field values ​​from the set of fields to be encrypted, and read the field position and key identifier corresponding to the field value according to the correspondence; Extract the encryption key from the key record according to the key identifier, and use the encryption key to encrypt the field value to obtain the ciphertext field corresponding to the field position; The verification value is generated according to the order of plaintext fields, field positions, ciphertext fields, key identifiers, HTTPS termination node records, and service forwarding node records in the encrypted data packet, and then encapsulated into an encrypted data packet containing plaintext fields, field positions, ciphertext fields, key identifiers, HTTPS termination node records, service forwarding node records, and the verification value.

6. The protocol transmission method based on custom encryption according to claim 1, characterized in that, The key validity period is recalibrated based on the node's reception time. The fields to be decrypted are determined by combining the field location, key identifier, and checksum, including: Read the field positions, ciphertext fields, key identifiers, and checksums from the encrypted data packets, and read the node reception times from the HTTPS termination node record and service forwarding node record in the encrypted data packets; The key validity period of the key record is recalibrated according to the node's reception time, and the decryption key record corresponding to the key identifier is read from the key record after the key validity period is recalibrated. The checksum is regenerated according to the field position, ciphertext field, and key identifier. When the regenerated checksum is the same as the checksum in the encrypted data packet, the ciphertext field is used as the field to be decrypted to determine the field to be decrypted.

Images