A data source-based secure chip encryption design method

Abstract

This invention relates to the field of IoT data security transmission technology, and particularly to a secure chip encryption design method based on a data source. The method includes: collecting, registering, and encrypting raw data using a secure chip on the terminal side to generate complete encrypted data units; performing integrity checks and unit recovery on the byte stream in the receiving buffer based on the encrypted data length on the gateway side, and, after successful verification, routing the data to transparent transmission, decryption, or key update paths according to the encryption / decryption status; simultaneously constructing downlink encrypted data units with the same structure and transmitting them back to the terminal; and updating the reuse configuration of the protocol version, encryption / decryption status, and length fields based on the recovery results. This invention solves the problem of invisible unit boundaries in TCP byte stream transmission of encrypted data through dual-length collaboration and cross-packet boundary recovery mechanisms, achieving a bidirectional secure transmission closed loop and improving system reliability and processing efficiency.

Description

Technical Field

[0001] This invention relates to the field of IoT data security transmission technology, and in particular to a secure chip encryption design method based on a data source. Background Technology

[0002] In the field of IoT data security transmission technology, existing solutions typically adopt a technical approach of raw data acquisition, writing to the write interface, encryption by a security encryption chip, transmission by the communication module, and reception by the business server. This approach has limitations such as the security encryption chip output directly entering the transmission channel, the receiving side processing data according to network data packets or ordinary receiving buffers, and encryption / decryption status and key updates being scattered in different processing stages.

[0003] Existing methods often rely on security encryption chips to complete encryption and decryption, random number generation, message authentication codes, public key verification, or key update processing, or rely on gateway-side channel encryption and network data packet processing paths. It is difficult to organize the output results of security encryption chips into a unified object for transmission and reception processing.

[0004] In scenarios where complete encrypted data units are sent via TCP and written into the receive buffer, unstable start identifier positioning and discontinuous encrypted data length determination can easily occur, making it difficult to meet the requirements for stable implementation of complete unit verification records and encryption / decryption status processing. In existing solutions, encrypted data output by the security encryption chip is often sent directly as ciphertext, and the receiving side often reads the byte stream in arrival order, resulting in inconsistent boundaries between network data packets and business data. When the encryption header and encrypted data are in different receiving processes, multiple complete encrypted data units continuously enter the same receive buffer, and there is no unified correspondence between data length and encrypted data length, the receiving side finds it difficult to determine in a timely manner whether a complete processing unit has been formed. The resulting impact is that the uplink and downlink processing on the business server side are prone to instability, and the terminal reception and security encryption chip recovery processing are also difficult to run continuously along the same field link.

[0005] For the joint processing of complete encrypted data units, TCP transmission, receiving buffer writing, complete unit verification record, and encryption / decryption status processing, existing technologies generally lack the technical arrangement to place data length, encrypted data length, start identifier, protocol version, encryption / decryption status, and verification value in the same processing chain. This makes it difficult to form a consistent process of acquisition, encryption, construction, transmission, extraction, judgment, processing, and updating in IoT data security transmission scenarios. As a result, complete encrypted data units are difficult to be stably recovered on the receiving side, and there is a lack of continuous correspondence between complete unit verification record and encryption / decryption status processing. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention provides a data source-based secure chip encryption design method, comprising:

[0007] S100: Obtain the raw data, starting identifier, and protocol version from the data source; perform data collection and registration processing; and encrypt the data using a security encryption chip to obtain a complete encrypted data unit.

[0008] The data source is provided by the data acquisition module in the acquisition terminal or the service interface connected to the main control chip of the terminal device; the raw data is the acquired data that has not yet entered the security encryption chip for processing; the start identifier is the magic number subsequently written into the encryption header; and the protocol version is the version number subsequently written into the encryption header.

[0009] S200. Based on the complete encrypted data unit, perform TCP sending processing and receiving buffer writing processing to obtain the complete unit verification record;

[0010] S300. Based on the complete unit verification record, perform encryption / decryption status splitting and uplink processing to obtain downlink encrypted data unit records.

[0011] S400. Based on the downlink encrypted data unit record, perform terminal reception processing, security encryption chip recovery processing, and reuse configuration update processing to obtain the updated original data and protocol configuration record.

[0012] Furthermore, the process of data collection, registration, and processing includes:

[0013] The data collection and registration process includes: registering the original data, starting identifier, and protocol version in the main control chip of the terminal device, and retaining the registration results without entering the encryption path of the security encryption chip when the communication module is interrupted.

[0014] Furthermore, the encryption process of the security encryption chip includes:

[0015] The original data is written to the security encryption chip through the write interface, and the security encryption chip performs padding and encryption. Then, the encrypted data is output to the main control chip of the terminal device through the read interface, and the data length and encrypted data length corresponding to the encrypted data are read simultaneously. The data length represents the effective length of the original data, and the encrypted data length represents the length after padding and encryption by the security encryption chip.

[0016] Furthermore, the process of obtaining a complete encrypted data unit includes:

[0017] The process of obtaining a complete encrypted data unit includes: performing encryption header writing, encryption / decryption status writing, and verification value appending processing in the main control chip of the terminal device;

[0018] The encryption header writing includes: sequentially writing the start identifier, protocol version, encryption / decryption status, data length, and encrypted data length, wherein the encryption / decryption status field reserves three values ​​in the same position: unencrypted state, encrypted state, and key update state;

[0019] The verification value appending process includes: performing verification calculations on the continuous content from the start identifier to the end of the encrypted data and appending the verification result to the encrypted data to obtain a complete encrypted data unit consisting of an encryption header, encrypted data, and a verification value.

[0020] Furthermore, the process of writing to the receive buffer includes:

[0021] The encrypted gateway continuously appends the TCP byte stream to the receive buffer and records the current write position and the current data volume. Bytes that were not read in the previous round are retained together with the newly received bytes.

[0022] Furthermore, the process of obtaining a complete cell verification record includes:

[0023] The process of obtaining a complete unit verification record includes: performing a start identifier lookup and encryption header reading in the receiving buffer to obtain an encryption header positioning record containing the start identifier position, protocol version, encryption / decryption status, data length, and encrypted data length;

[0024] Based on the length of encrypted data in the encrypted header location record, determine whether all bytes required for a complete encrypted data unit have been received from the starting identifier position.

[0025] When the readable length is insufficient, retain the encrypted header location record and wait for subsequent TCP writes before making another judgment;

[0026] When the readable length is reached, the continuous content from the start identifier position to the end of the encrypted data is truncated, the check value is recalculated, and compared with the received check value to obtain a complete unit check record containing the boundary position, integrity check status and encryption header field.

[0027] Furthermore, the encryption / decryption state splitting process includes:

[0028] Read the encryption / decryption status field from the complete unit verification record, and assign the unencrypted status to the pass-through processing path, the encrypted status to the decryption processing path, and the key update status to the key update data reading path.

[0029] Furthermore, the uplink processing to obtain the downlink encrypted data unit record includes:

[0030] The uplink processing includes: transparently transmitting unencrypted data, and decrypting and extracting valid data from encrypted data based on the data length and the encrypted data length.

[0031] The process of obtaining the downlink encrypted data unit record includes: writing the start identifier, protocol version, encryption / decryption status, data length, encrypted data length, and appending a check value to the data returned by the service server or the key update data, thereby obtaining the downlink encrypted data unit record.

[0032] Furthermore, the terminal receiving and processing process includes:

[0033] The terminal device's main control chip reads the start identifier, protocol version, encryption / decryption status, data length, encrypted data length, and checksum from the downlink encrypted data unit record.

[0034] Furthermore, the process of recovering the security encryption chip and reusing the configuration update includes:

[0035] The security encryption chip recovery process includes: the terminal device's main control chip extracts encrypted data according to the encrypted data length and writes it into the security encryption chip, and reads the recovery result through the read interface, and truncates the valid data range according to the data length;

[0036] The reuse configuration update process includes: writing the protocol version and encryption / decryption status from the terminal recovery record back to the configuration registration area of ​​the next round of transmission path, and updating the data length and encrypted data length to obtain the updated original data and protocol configuration record written back to the collection registration process.

[0037] The key innovations of this invention include:

[0038] (1) Based on the encrypted data and length record, perform encryption header writing, encryption / decryption status writing and check value appending processing to obtain a complete encrypted data unit; wherein, the complete encrypted data unit organizes the start identifier, protocol version, encryption / decryption status, data length, encrypted data length, encrypted data and check value in the same processing object, and serves as the unified input object for subsequent TCP sending, receiving buffer writing, start identifier lookup, encryption header reading, encrypted data length judgment, integrity verification, encryption / decryption status identification and downlink complete encrypted data unit construction processing.

[0039] (2) Based on the encrypted header location record, perform encrypted data length judgment and integrity verification to obtain a complete unit verification record; wherein, the encrypted data length judgment and integrity verification are not executed separately, but are executed sequentially around the boundary position, encrypted data length and verification value of the same complete encrypted data unit, so that the byte stream in the receiving buffer first completes the complete unit formation judgment, and then enters the integrity verification and subsequent encryption and decryption state processing.

[0040] (3) Obtain the complete unit verification record, perform encryption / decryption status identification and processing path registration processing to obtain the status split record; and based on the status split record and the uplink processing record, perform key update data reading, valid data encryption and downlink complete encrypted data unit construction processing to obtain the downlink encrypted data unit record; and based on the terminal recovery record, perform protocol version reuse configuration and encryption / decryption status reuse configuration, and perform data length update and check value update processing to obtain the updated original data and protocol configuration record, thereby organizing uplink processing, downlink processing and protocol configuration update into a continuous processing process in the same link.

[0041] The following are its main beneficial effects:

[0042] (1) In view of the problem that the output results of the security encryption chip directly enter the transmission channel in the prior art and the receiving side is difficult to process around a unified object, the present invention organizes the start identifier, protocol version, encryption and decryption status, data length, encrypted data length, encrypted data and check value through a complete encrypted data unit, so that the terminal device main control chip, security encryption chip, encryption gateway and business server perform sending, extraction, judgment and processing around the same processing object, and the complete encrypted data unit maintains a consistent field structure in the uplink and downlink.

[0043] (2) In view of the problems in the prior art that the boundaries between network data packets and business data are inconsistent and that it is difficult to determine in time whether a complete processing unit has been formed in the receiving buffer, the present invention forms a complete unit verification record by continuously processing the encrypted data length judgment and integrity verification, so that the data processing object on the receiving side is transformed from the contents of the ordinary receiving buffer to a complete encrypted data unit, and the encrypted header in the receiving buffer is processed along the same judgment link across the receiving process, the encrypted data is processed across the receiving process, and the continuous entry scene is processed along the same judgment link.

[0044] (3) In view of the problem that encryption and decryption status and key update are scattered in different processing stages in the prior art, the present invention forms a status split record by identifying encryption and decryption status and registering processing paths, and calls the status split record in the transparent transmission processing, decryption processing, key update data reading and downlink complete encrypted data unit construction processing, so that the business data path and key update path are processed in the same status field system, and the encryption and decryption status processing and the complete unit verification record maintain a continuous correspondence.

[0045] (4) In view of the problem that the data length and encrypted data length are not uniformly corresponding in the prior art and the effective data boundary after decryption is separated from the receiving side unit boundary, the present invention introduces both data length and encrypted data length in the complete encrypted data unit, and continuously calls the data length and encrypted data length in the receiving buffer unit extraction, transparent transmission processing, decryption processing and terminal receiving recovery processing, so that the receiving side unit boundary judgment and the recovery of effective data are executed along the same field link.

[0046] (5) In view of the problem that the uplink processing, downlink processing and protocol configuration update are separated in the prior art, and the terminal receiving and security encryption chip recovery processing are difficult to run continuously along the same field link, the present invention enables the protocol version reuse configuration, encryption and decryption status reuse configuration, data length update and check value update to enter the next round of collection and registration processing path through the continuous transmission of downlink complete encrypted data unit construction, terminal recovery record, reuse configuration record and updated original data and protocol configuration record, forming a continuous processing link around the original data and protocol configuration record. Attached Figure Description

[0047] Figure 1 A flowchart illustrating a data source-based security chip encryption design method provided in this application embodiment;

[0048] Figure 2 This is a structural block diagram of a data source-based security chip encryption design method provided in an embodiment of this application. Detailed Implementation

[0049] Example 1: Refer to Figure 1 This is a flowchart illustrating a data source-based security chip encryption design method provided by an embodiment of the present invention. The process may include at least steps S100-S400:

[0050] S100: Obtain the raw data, starting identifier, and protocol version from the data source; perform data collection and registration processing; and encrypt the data using a security encryption chip to obtain a complete encrypted data unit.

[0051] S200. Based on the complete encrypted data unit, perform TCP sending processing and receiving buffer writing processing to obtain the complete unit verification record;

[0052] S300. Based on the complete unit verification record, perform encryption / decryption status splitting and uplink processing to obtain downlink encrypted data unit records.

[0053] S400. Based on the downlink encrypted data unit record, perform terminal reception processing, security encryption chip recovery processing, and reuse configuration update processing to obtain the updated original data and protocol configuration record.

[0054] Step S100 includes at least steps S110-S130:

[0055] S110. Obtain the raw data, starting identifier, and protocol version from the data source, perform collection and registration processing, and obtain the raw data and protocol configuration records;

[0056] Specifically, the data source is provided by the data acquisition module in the acquisition terminal or the service interface connected to the main control chip of the terminal device. The raw data is the acquired data that has not yet entered the security encryption chip for processing. The starting identifier is the magic number subsequently written into the encryption header. The protocol version is the version number subsequently written into the encryption header.

[0057] The terminal device's main control chip triggers this step when the communication module is online, the write interface is writable, and there is raw data to be sent. In engineering implementation, this step can be triggered by the acquisition terminal according to the transmission cycle, or by the arrival of raw data. The acquisition and registration process includes receiving raw data, calling the start identifier, calling the protocol version, and registering the three according to the same transmission unit.

[0058] The registration here is not simply saving text, but rather the terminal device's main control chip forming a field correspondence according to the writing order of the subsequent security encryption chip, so that the original data, the starting identifier, and the protocol version maintain the same processing path in subsequent steps.

[0059] Furthermore, when performing data acquisition and registration processing, the main control chip of the terminal device performs preliminary checks on whether the original data is empty, whether the starting identifier is missing, and whether the protocol version is not configured. When the original data is empty, the write interface is not entered in this round. When the starting identifier or protocol version is not registered, the registered content in the local protocol configuration is called to complete the supplementary recording. When the communication module experiences a temporary interruption, only the registration results of the original data and protocol configuration are retained, and the encryption path of the security encryption chip is not entered.

[0060] Understandably, the start identifier and the protocol version are core fields in the protocol configuration. The former is used for lookup in the subsequent receive buffer, and the latter is used for version identification after reading the encryption header. Therefore, in this step, registration needs to be completed before the write operation of the write interface.

[0061] Through the above processing, the terminal device's main control chip organizes the raw data, the starting identifier, and the protocol version into an output field named "Raw Data and Protocol Configuration Record," and provides this output field for subsequent S120 as a direct input. During closed-loop operation, the updated raw data and protocol configuration record output by S430 can be written back to this step as the basis for the next round of data collection and registration processing, thereby ensuring a continuous connection between this step and S200, S300, and S400.

[0062] S120. Based on the original data and protocol configuration record, perform write interface writing, security encryption chip encryption and read interface reading to obtain encrypted data and length record;

[0063] Specifically, after the original data and protocol configuration record enter this step, the main control chip of the terminal device first parses out the original data, and then calls the write interface to write to the security encryption chip according to the original data.

[0064] The write interface here is the serial port interface between the terminal device's main control chip and the security encryption chip. The content written is the raw data to be processed, and the writing order follows the order in which the raw data is arranged during registration and processing. After receiving the raw data, the security encryption chip performs encryption processing. In this embodiment, the national cryptographic algorithm 4 electronic codebook mode, namely the SM4-ECB mode, is used, where "SM4" is a commercial cryptographic block algorithm and "ECB" is an electronic codebook mode.

[0065] Before encrypting the original data, the terminal device's main control chip or security encryption chip performs padding processing according to a preset block length, and simultaneously generates the data length and the encrypted data length; the data length is used to represent the effective length of the original data, and the encrypted data length is used to represent the length after padding and encryption processing by the security encryption chip.

[0066] Furthermore, after the security encryption chip completes the encryption process, it outputs encrypted data to the terminal device's main control chip via the read interface. The read interface corresponds to the write interface and still uses a serial port interface for reading, with the reading order matching the writing order. During the read interface processing, the terminal device's main control chip not only reads the encrypted data itself but also simultaneously reads the corresponding data length and the encrypted data length, and registers the length consistency of the read data. When the encrypted data returned by the read interface is empty, the data length is missing, or the encrypted data length is missing, this round of processing only retains the original data and protocol configuration record, and does not proceed to the encryption header writing action.

[0067] Understandably, the encryption chip encryption and the read interface reading in this step are not two isolated actions, but a sequential processing chain completed around the same original data. The former generates encrypted data, and the latter retrieves the encrypted data and brings out the length information. The encryption header field and check value field required by S130 are all built on this record.

[0068] Through the above processing, the main control chip of the terminal device organizes the encrypted data, the data length, and the encrypted data length into an output field name "encrypted data and length record", and provides this output field as a direct input for subsequent S130; this output field also forms the basis for length judgment after the complete encrypted data unit is formed in S200.

[0069] S130. Based on the encrypted data and length record, perform encryption header writing, encryption / decryption status writing, and check value appending processing to obtain a complete encrypted data unit.

[0070] Specifically, after obtaining the encrypted data and length record, the main control chip of the terminal device first extracts the encrypted data, data length and encrypted data length from it, and then calls the start identifier and protocol version registered in S110 to write it into the encryption header.

[0071] The encryption header is a set of fixed fields located before the encrypted data, including at least a start identifier, protocol version, encryption / decryption status, data length, and encrypted data length. The start identifier is used for start identifier lookup in subsequent S220, the protocol version is used for encryption header reading in subsequent S220, the encryption / decryption status is used for encryption / decryption status identification in subsequent S310, and the data length and encrypted data length are used for encrypted data length determination in subsequent S230 and recovery of the original data after decryption.

[0072] Furthermore, in this embodiment, the encryption / decryption state reserves at least three values: unencrypted state, encrypted state, and key update state. For the current uplink transmission path, when the terminal device's main control chip writes the encryption / decryption state, it registers the service data as encrypted and retains the field positions for unencrypted state and key update state, so that the complete encrypted data unit can be processed by the encryption gateway in a unified format after entering the S300.

[0073] After the encryption header is written, the terminal device's main control chip continues to perform checksum appending processing. The checksum uses a 16-bit Cyclic Redundancy Check (CRC) checksum, specifically CRC16. In this embodiment, the checksum is used to continuously verify the data from the start identifier to the end of the encrypted data, and the verification result is appended to the end of the encrypted data. This checksum appending processing differs from existing paths that only transmit ciphertext; its processing object is not a single encrypted data item, but rather the sending unit containing both the encryption header and encrypted data. Therefore, it can be directly used for integrity verification in subsequent step S230.

[0074] In specific implementation, after completing the encryption header writing, the terminal device's main control chip first locks the first byte position of the start identifier, then sequentially concatenates the protocol version, encryption / decryption status, data length, encrypted data length, and encrypted data, and then appends the verification value to form a complete encrypted data unit for TCP protocol stack transmission. When the encryption header field is incomplete, the encrypted data is empty, or the verification value is not generated, the complete encrypted data unit is not output in this round, but instead the encrypted data and length record are retained for reprocessing. Through the above processing, the terminal device's main control chip records the result of the combination of the encryption header, the encrypted data, and the verification value as the output field name "Complete Encrypted Data Unit," and directly provides this output field for subsequent S210 calls. After entering S200, this output field undergoes TCP send and receive buffer writing processing and continues to participate in the start identifier lookup in S220, the integrity verification in S230, the encryption / decryption status identification in S310, and the downlink complete encrypted data unit construction in S330. Therefore, this step constitutes the core field transmitted from S100 to S200, S300, and S400.

[0075] The key technical effect of this step is that it rewrites the encrypted data output by the security encryption chip from simple ciphertext into a complete encrypted data unit containing a start identifier, protocol version, encryption / decryption status, data length, encrypted data length, and checksum. This provides subsequent steps with a unified reading entry point, a unified length reference, and a unified status entry point. Compared to processing paths that only output the encryption result, this step places the encrypted data, length information, and processing status into the same sending unit, providing a direct basis for subsequent receive buffer processing and status splitting.

[0076] In one specific embodiment, in S130, based on the encrypted data and length record, encryption header writing, encryption / decryption status writing, and checksum appending are performed to obtain a complete encrypted data unit. The input to this step comes from the encrypted data and length record output from S120, which already contains three basic fields: encrypted data, data length, and encrypted data length returned by the security encryption chip via the read interface. Simultaneously, this step also needs to retrieve the registered start identifier and protocol version from the original data and protocol configuration record output from S110. The terminal device's main control chip first parses the encrypted data and length record, extracting the encrypted data body, data length value, and encrypted data length value. Then, it loads the start identifier, protocol version, and encryption / decryption status value corresponding to the current uplink transmission path into the encryption header construction buffer. The encryption header construction buffer is a continuous byte sequence with a fixed length, written sequentially by the terminal device's main control chip according to a predefined field order. This order can be represented as an encryption header vector. The composition of the data is such that its components correspond to the numerical representations of each field. To clearly describe this field arrangement process mathematically, the following formulation is established.

[0077] Formula①

[0078]

[0079] Variable and symbol definition:

[0080] As defined in the original text, it is an "encrypted header vector," a column vector consisting of five fields arranged in sequence, with dimensions of [dimension number missing]. Bytes (total of eight bytes for all fields);

[0081] The value is defined as "starting identifier field value" in the original text. It originates from the starting identifier in the S110 raw data and protocol configuration record and has a value of a two-byte fixed magic number (in this embodiment). );

[0082] This field, defined as "protocol version value" in the original text, originates from the protocol version in the S110 raw data and protocol configuration record. Its value is a single-byte unsigned integer, and its range is... to ;

[0083] This has been defined in the original text as the "encryption / decryption status field value," which is written by the terminal device's main control chip according to the current transmission path. The uplink encryption status is retrieved from... At the same time, the unencrypted state is retained. Key update status The field space;

[0084] The value is defined as "data length field value" in the original text. It comes from the data length in the S120 encrypted data and length record. The value is a two-byte unsigned integer, which represents the number of valid bytes in the original data before it is padded.

[0085] The value of the encrypted data length field, as defined in the original text, comes from the encrypted data length in the S120 encrypted data and length record. It is a two-byte unsigned integer, representing the total number of bytes of the original data after padding and encryption by the security encryption chip.

[0086] The term "column vector" has already been indirectly explained in the original text; here, we provide a clear definition: superscript. This represents the transpose operation of a matrix or vector, here converting a row vector into a column vector.

[0087] Simple numerical example: Set the starting identifier (i.e., decimal) ), protocol version Encryption / decryption status Data length byte (i.e.) ), encrypted data length byte (i.e.) The encryption header vector, in byte order, can then be written as: It contains eight bytes in total.

[0088] The terminal device's main control chip completes the encryption header vector. After the first byte is written, it is not sent immediately. Instead, the encrypted header byte sequence is concatenated with the encrypted data byte sequence to form a data segment to be verified. This data segment begins with the first byte of the start identifier and ends at the end of the encrypted data, excluding the subsequently appended checksum field. To describe the structure of this data segment, an extension vector is introduced. It consists of an encrypted header vector. With encrypted data vectors Concatenated sequentially. Encrypted data vector. The encrypted data field, derived from the S120 encrypted data and length record, has a length of [length value missing]. Bytes. Therefore, the data segment to be verified can be expressed as follows.

[0089] Formula②

[0090]

[0091] Variable and symbol definition:

[0092] : As defined in the original text, it is "the data vector to be verified," which is composed of the encryption header vector. With encrypted data vectors The column vector formed by sequentially concatenating the columns has a total length of byte;

[0093] Same as the definition in formula ①, used as input here;

[0094] : Defined in the original text as an "encrypted data vector," it originates from the encrypted data in the S120 encrypted data and length record, and its dimension is (i.e., the length value of the encrypted data), each component is a single-byte ciphertext output by the security encryption chip;

[0095] : for encryption header vector The transpose of is used to obtain a row vector form, and the components are expanded in byte order.

[0096] : for encrypted data vectors The transpose of gives the row vector form, which can be used with ... Sequential connection;

[0097] Additional definition: Commas within square brackets indicate horizontal concatenation of vectors, and outer transpose. This means converting the concatenated row vectors back into column vectors, thus obtaining... The column vector representation of .

[0098] Simple numerical example: Continuing from the previous example, let's assume the length of the encrypted data is... Encrypted data vector Examples of the first few bytes are The data vector to be verified. The total length is The data consists of 144 bytes, with the following contents in sequence: two bytes for the start identifier, one byte for the protocol version, one byte for the encryption / decryption status, two bytes for the data length, two bytes for the encrypted data length, followed by 144 bytes of encrypted data.

[0099] During project implementation, the terminal device's main control chip writes the encryption header field into an internal buffer, and then uses direct memory access to transfer the encrypted data vector. The data is copied from the buffer corresponding to the read interface to the encryption header. After concatenation, the main control chip immediately initiates the checksum calculation process. In this embodiment, the checksum uses a 16-bit cyclic redundancy check (CRC16), whose generator polynomial is... The corresponding hexadecimal representation is The CRC16 calculation process can be viewed as occurring within the Galois domain. Polynomial division is used to process the input data bitstream bit by bit. Since the terminal device's main control chip runs in an embedded environment, a byte-by-byte lookup table method is used to accelerate the calculation; however, the recursive logic is described here in mathematical iteration form to clarify the technical details. Let the data vector to be verified be... Include bytes, of which Each byte is denoted as The initial value of the CRC16 register is set to... For each input byte, perform the following update.

[0100] Formula③

[0101]

[0102] Variable and symbol definition:

[0103] : already defined in the original text as "before processing" The CRC register status value after 1 byte, with a value range of 1. initial value ;

[0104] : This has been defined as the iteration step index in the original text, and its value is from... arrive non-negative integers;

[0105] : Defined in the original text as the data vector to be verified The total number of bytes, i.e. ;

[0106] : has been defined in the original text as "data vector to be verified" The first in "One byte" comes from the vector components output by formula ②;

[0107] The original text already defines it as "left shift operation (bitwise operation)". The definition is as follows: Indicates integer Shift the binary bits to the left Filling the right side with zeros is equivalent to multiplying by 1 / 2. This is used for byte alignment;

[0108] The original text already described it as a "right shift operation (bitwise operation)", so the following definition is provided: Indicates integer Shift the binary bits to the right Filling the left side with zeros (for unsigned numbers) is equivalent to dividing by . And round down;

[0109] The binary bitwise XOR operation returns a result when corresponding bits of the two operands are different. The same as ;

[0110] The original text already stated "bitwise AND". Here is a supplementary definition: Binary bitwise AND operation, where corresponding bits of both operands are equal. The result is Otherwise This is used for masking operations to extract the lower eight bits;

[0111] Hexadecimal constants have a decimal value of binary is , used as a mask to extract the lower eight bits of a byte;

[0112] Hexadecimal constant, decimal value The binary number is sixteen. This is used to ensure that the calculation result remains within the range of sixteen bits;

[0113] The original text defines it as a "pre-calculated CRC16 lookup table," which contains... A set of sixteen-digit unsigned integers, with entries based on the generator polynomial. Preset. Additional information: Represented by byte value Retrieve the corresponding CRC remainder value from the lookup table using the index;

[0114] : As defined in the original text, the updated CRC register status value is the target variable for iterative recursion.

[0115] Simple numerical example: Taking the first three bytes of the data vector to be verified as an example, let's assume... , , .initial .right : Calculate first ,and XOR From the table, we can find (Example value), then with XOR After communicating with Position and after .right :by Repeat the steps until the final verification value is obtained after iterating through all 152 bytes. In actual engineering, the main control chip of the terminal device stores this lookup table in the program memory and performs a complete traversal once for each complete encrypted data unit to be sent.

[0116] After completing the CRC16 calculation, the terminal device's main control chip splits the resulting 16-bit checksum into two bytes and appends them to the encrypted data in low-order, high-order byte order. This appending action forms the final complete encrypted data unit vector. Its structure can be described as follows:

[0117] Formula④

[0118]

[0119] Variable and symbol definition:

[0120] As defined in the original text, it is a "complete encrypted data unit vector," consisting of the data vector to be verified. It is formed by concatenating two checksum bytes in sequence, with a total length of byte;

[0121] Same as the definition in formula ②;

[0122] The value of the final output register in Formula ③ has been defined in the original text. The lower octet, i.e. ;

[0123] The value of the final output register in Formula ③ has been defined in the original text. "High octave", that is ;

[0124] : Column vector Transpose it into a row vector so that it can be horizontally concatenated with subsequent bytes;

[0125] Transpose the horizontally concatenated row vectors into column vectors to obtain... The column vector representation of .

[0126] Simple numerical example: If the final result obtained through iteration of formula ③ is... ,but , At this point, the complete encrypted data unit vector... The length is 154 bytes, of which the last two bytes are respectively: and The terminal device's main control chip writes this vector into the communication module's transmit buffer, preparing to execute the S210's TCP send process.

[0127] During the construction of a complete encrypted data unit, the terminal device's main control chip also needs to determine and roll back from abnormal situations. If the encrypted header vector... If any required field is missing (e.g., the start identifier was not correctly retrieved from S110, the data length or encrypted data length is zero), or the encrypted data vector... If the value is empty, or the checksum calculation was not completed successfully, then this round of processing will not output a complete encrypted data unit vector. Instead, it retains the current encrypted data and length record in the main control chip's rollback buffer and registers the exception type. To quantify this rollback decision in engineering, an integrity indicator variable is introduced. Its value is determined by the existence of each field and the validation readiness status. This decision-making process can be formalized as the following piecewise function.

[0128] Formula⑤

[0129]

[0130] Variable and symbol definition:

[0131] It has been defined in the original text as a "binary integrity indicator variable", with a value of This indicates that the construction is valid. This indicates that the construction failed;

[0132] Same as the definition in formula ①;

[0133] Same as the definition in formula ①;

[0134] Same as the definition in formula ①;

[0135] Same as the definition in formula ①;

[0136] : "The actual dimension of the encrypted data vector"; function Return vector Byte length (dimension);

[0137] It has been defined as CRC16 iteration in formula ③. The final register value after this;

[0138] The following has been indirectly mentioned in the original text ("and"): The logical AND operator means that the whole is true when both conditions are true.

[0139] “ "Valid": As defined in the original text, "no hardware abnormality or timeout occurred during the calculation process," it is used here as a logical condition and does not require a quantization symbol.

[0140] Simple numerical example: In the previous example, , , , The actual encrypted data vector length is equal to Bytes, and the CRC calculation has returned a valid value. Therefore The main control chip of the terminal device will Submit to the communication module's send queue. If an exception occurs at any stage, such as the read interface returning insufficient encrypted data length, then... No output in this round. The encrypted data and length record are rolled back and retained.

[0141] In practical engineering implementation, the data acquisition terminal may experience intermittent communication interruptions or high load conditions, requiring a re-initiation of the encryption header writing and checksum appending process after a failed construction. To manage this retry behavior without introducing complex control logic, the terminal device's main control chip maintains a retry counter associated with the current encrypted data and length record, denoted as... The counter counts each time... The increment occurs during rollback, upon successful construction. Then clear to zero. To avoid unlimited retries consuming main control chip resources, a maximum retry threshold is set. (In this embodiment, the value is taken as) The update rules for the retry counter can be expressed as follows.

[0142] Formula⑥

[0143]

[0144] Variable and symbol definition:

[0145] : As defined in the original text, "the number of retries corresponding to the current encrypted data and length record", with a value range of non-negative integers;

[0146] The assignment operator assigns the result of the expression on the right to the variable on the left.

[0147] Same as the definition in formula ⑤;

[0148] The term "preset maximum retry threshold" has been defined in the original text and takes the value of a positive integer. In this implementation, it is used in conjunction with the following: ;

[0149] "Retain current value": This has already been explained in the original text, meaning... No change, no extra symbols required.

[0150] Simple numerical example: Let the initial... This round was caused by insufficient length of the encrypted data vector. According to formula ⑥, Updated to The main control chip waits one hundred milliseconds before retrying to read and construct. If the second attempt also fails, Become If the third success makes ,but Clear the string and output the complete encrypted data unit. If it fails three times consecutively, then... achieve No further attempts will be made, and the record will be moved to the exception storage area.

[0151] After completing the above processing, the terminal device's main control chip will fully encrypt the data unit vector. Together with its associated integrity indication Together with the retry status, it is organized into an output field named "Complete Encrypted Data Unit". This output field is subsequently used as direct input in S210 and transmitted to the encryption gateway by the TCP sending processing module in byte stream mode. At the same time, the encryption header fields (including start identifier, protocol version, encryption / decryption status, data length, and encrypted data length) and checksum fields in the complete encrypted data unit will participate in the start identifier lookup in S220, the encrypted data length judgment and integrity verification in S230, the encryption / decryption status identification in S310, and the downlink complete encrypted data unit construction in S330 in sequence.

[0152] The technical effect of this section can be summarized as follows: the encrypted data and length information output by the security encryption chip are transformed into a complete encrypted data unit with self-describing capabilities through the construction of encryption header vector and the addition of verification value. The reliability of the unit generation is ensured through integrity indication and retry management mechanism, so that subsequent steps can be received and processed under unified field boundaries and verification rules.

[0153] Step S200 includes at least steps S210-S230:

[0154] S210. Obtain the complete encrypted data unit, perform Transmission Control Protocol (TCP) send and receive buffer write processing, and obtain the receive buffer write record.

[0155] Specifically, the complete encrypted data unit originates from the preceding step S130, and this complete encrypted data unit already includes a start identifier, protocol version, encryption / decryption status, data length, encrypted data length, encrypted data, and checksum. Therefore, this step does not further split the field content; instead, the terminal device's main control chip organizes and sends the data units in the order they appear. The TCP transmission is completed by the terminal device's main control chip through a data connection established between the communication module and the encryption gateway. The transmission triggering conditions include the existence of a complete encrypted data unit to be sent, the communication module being in a connected state, the encryption gateway being in a receiving state, and the previous round of transmission buffer being released. If any condition is not met, the current round of transmission is paused, and the complete encrypted data unit is retained in the terminal device's main control chip's transmission path until the connection is restored.

[0156] Understandably, the TCP only carries the byte stream. When the complete encrypted data unit is sent, it may correspond one-to-one with a single network data packet, or it may be split into multiple network data packets, or it may be continuously arranged into the same network data packet with the next complete encrypted data unit. Therefore, the encryption gateway does not decrypt the network data packet directly, but writes it into the receiving buffer first.

[0157] Furthermore, the receiving buffer is set in the agent program of the encryption gateway and belongs to the data buffer on the receiving path. The receiving buffer includes at least three registered contents: buffer capacity, current write position, and current data volume. The buffer capacity is used to record the range of data that the receiving buffer can accept, the current write position is used to record the end position of this write, and the current data volume is used to record the amount of data in the current receiving buffer that has not yet been read by subsequent steps. After receiving the byte stream sent by the terminal device's main control chip via TCP, the encryption gateway first writes the received byte stream sequentially into the receiving buffer, and then registers the start position, end position, and write length corresponding to this write. The write process here is not a simple overwrite, but a continuous append; bytes that have not been read by subsequent steps in the previous round are still retained in the receiving buffer, and together with the newly received bytes in this round, they constitute the receiving buffer write record called by S220.

[0158] In a feasible engineering embodiment, the acquisition terminal is connected to a security encryption chip and a communication module, and the service server communicates with the acquisition terminal through an encryption gateway. After the main control chip of the terminal device forms a complete encrypted data unit in S130, it continuously sends it to the encryption gateway via the communication module. If the first half of a complete encrypted data unit enters the current network data packet and the second half enters the next network data packet, the encryption gateway agent program, upon receiving the first half, first writes the first half into the receiving buffer and registers the current data volume; when the next network data packet arrives, it continues to write the second half into the same receiving buffer. If two complete encrypted data units arrive consecutively in the same network data packet, the encryption gateway also writes them into the receiving buffer in the same receiving order, distinguishing the total write length and the current cumulative data volume in the registration content, without performing field pruning in this step. In this way, the receiving buffer writing process forms a unified receiving entry on the encryption gateway side, and subsequent steps can complete the start identifier lookup and complete unit judgment in the same receiving buffer.

[0159] Through the above processing, this step records the received result of the complete encrypted data unit on the encryption gateway side as the output field name "Receive Buffer Write Record", and uses this output field as a direct input for subsequent S220; at the same time, the Receive Buffer Write Record constitutes the prerequisite for S230 to perform encrypted data length judgment and integrity verification, and maintains a continuous correspondence with the encryption and decryption status identification path of S300.

[0160] S220. Based on the record written in the receiving buffer, perform start identifier lookup and encryption header reading processing to obtain encryption header positioning record;

[0161] Specifically, after the record is written to the receive buffer in this step, the encryption gateway agent program performs a start identifier lookup starting from the current start read position of the receive buffer.

[0162] The starting identifier is the first field of the encryption header in the complete encrypted data unit. During the search process, the encryption gateway agent program compares the contents in the receiving buffer with the starting identifier in byte order. When the comparison is successful, the position is registered as a candidate starting position of the encryption header. When the comparison fails, the reading position is shifted forward and the search continues.

[0163] The lookup process here targets a continuous stream of bytes in the receive buffer, not a single network packet. Therefore, if there are invalid bytes before the start identifier, the tail byte of the previous complete encrypted data unit, or multiple complete encrypted data units written consecutively, this step still scans in the same order. If the current amount of data in the receive buffer is insufficient to cover the length of the complete start identifier, the encryption gateway agent retains the current receive buffer write record, does not output the encryption header location record, and waits for the next round of S210 writes before re-executing this step.

[0164] Furthermore, after locating the start identifier, the encryption gateway agent does not immediately proceed with the decryption process. Instead, it reads the encryption header around the location of the start identifier. The encryption header reading process includes reading the protocol version, encryption / decryption status, data length, and encrypted data length in a fixed order, and registering the reading results along with the start identifier in the same record.

[0165] The protocol version is used to identify the version number corresponding to the current complete encrypted data unit, the encryption / decryption status is used for encryption / decryption status identification in subsequent S310, the data length is used for recovery of the original data after decryption, and the encrypted data length is used for complete unit judgment in subsequent S230.

[0166] Understandably, the encryption header reading in this step only reads the encryption header itself, not all encrypted data and checksums. This is because the starting position and header fields need to be determined first to form the boundary information upon which subsequent complete unit judgments depend. If the readable range of the receive buffer after the starting identifier is insufficient to cover the complete encryption header, the encryption gateway agent program reserves that starting position as a pending confirmation position and writes the current state back to the receive buffer write record, waiting for the next round of S210 to write subsequent bytes before continuing to read.

[0167] The following three implementation methods can be adopted in the project implementation.

[0168] In technical solution one, the encryption gateway agent program sequentially searches for the start identifier between the first and last addresses of the receive buffer, and immediately reads the encryption header in fixed byte numbers after finding it.

[0169] In technical solution two, the encrypted gateway agent program first determines the starting position of the current round of reading based on the end position of the previous complete unit verification, and then searches for the starting identifier from that position to reduce repeated scanning.

[0170] In technical solution three, the encrypted gateway agent program only performs a concatenation search on the newly written part and the tail-retained part from the previous round after each write operation, which is used to handle scenarios where the starting identifier is distributed across network data packets.

[0171] All three implementations maintain the same field order and read the same encrypted header content; the only differences are in the search starting point and the scan range.

[0172] Through the above processing, the encryption gateway agent program organizes the starting identifier position, protocol version, encryption / decryption status, data length, and encrypted data length into an output field name "encryption header location record", and provides this output field as a direct input for subsequent S230. At the same time, the encryption header location record is also the preliminary source of the status diversion registration in S300, because the subsequent encryption / decryption status identification depends on the encryption / decryption status field read in this step.

[0173] S230. Based on the encrypted header location record, perform encrypted data length judgment and integrity verification processing to obtain a complete unit verification record;

[0174] Specifically, after receiving the encryption header positioning record, the encryption gateway agent program first reads the starting identifier position and the length of the encrypted data, and then determines in the receiving buffer whether a complete encrypted data unit has been formed based on the encryption header length, the encrypted data length, and the check value length.

[0175] The encrypted data length determination here refers to calculating the total length occupied by the encryption header, encrypted data, and checksum sequentially from the start marker position, and comparing this total length with the readable length in the current receive buffer from the start marker position to the current write end position. When the readable length is less than the total length, this step does not output a complete unit verification record, but instead retains the current encryption header positioning record in the encryption gateway agent program, waiting for S210 to write the remaining bytes into the receive buffer before making another determination. When the readable length reaches the total length, it means that a complete encrypted data unit can be extracted from the start marker position, and at this time, the integrity verification process begins.

[0176] Furthermore, if there are still remaining bytes in the receive buffer after the complete encrypted data unit, these remaining bytes will remain in the receive buffer and will not be deleted in this step. Instead, they will be reserved for the next round of S220 to perform a new start identifier lookup, thereby supporting the operation scenario where multiple complete encrypted data units enter the same receive buffer consecutively.

[0177] Furthermore, the integrity verification process is performed by the encryption gateway agent program, which extracts the continuous content from the start identifier to the end of the encrypted data from the receiving buffer according to the start identifier position registered in the encryption header positioning record, recalculates the verification value according to the same verification rules, and compares the recalculated verification value with the verification value appended to the end of the complete encrypted data unit.

[0178] The integrity verification process here covers the entire encryption header and encrypted data, not just the encrypted data body. Therefore, if the start identifier is misread, the protocol version is incorrect, the encryption / decryption state is misaligned, the data length is truncated, the encrypted data length is abnormal, or the encrypted data content changes, these issues will all be identified in this step. If the comparison matches, the complete encrypted data unit is registered as a processable unit; if the comparison does not match, the complete encrypted data unit is registered as an invalid unit, and the process continues from the current start identifier position to prepare for a new start identifier lookup.

[0179] Specifically, when the encryption header is split into two network data packets, S220 only registers part of the encryption header information, and this step waits due to insufficient readable length; when the encryption header and encrypted data are in different network data packets, this step also waits based on the result of the encrypted data length judgment; when there is an invalid leading byte in the receive buffer, this step only performs length judgment and integrity verification on the part that has been found through the start identifier, and does not perform verification calculation on the invalid leading byte.

[0180] In a real-world scenario, the acquisition terminal continuously sends complete encrypted data units to the encryption gateway. The encryption header of the first complete encrypted data unit falls at the end of the previous network data packet, while the encrypted data and checksum fall in the next network data packet. The encryption gateway agent program only obtains the encryption header location record in the previous round and does not perform integrity verification. After the next network data packet arrives and is written to the receive buffer, this step recalculates the readable length, confirms that it covers the encrypted data length and checksum length, and then extracts the corresponding bytes starting from the start identifier for integrity verification. If the verification passes, the complete encrypted data unit is registered as a processing unit that can currently enter S310; if the verification fails, the subsequent bytes are retained, and a new start identifier is searched from the current start identifier.

[0181] Through the above processing, this step organizes the encrypted data length judgment result, integrity verification result, current complete encrypted data unit boundary position, and whether it enters the subsequent processing path into the output field name "Complete Unit Verification Record", and makes this output field available for S310 to use as direct input; after the complete unit verification record enters S300, it is used for encryption / decryption status identification and processing path registration, and also constitutes the premise for S320 transparent transmission processing and decryption processing.

[0182] The key technical effect of this step is to convert the continuous byte stream in the receive buffer into processable units with boundary positions and verification states, and to combine the encryption header reading result with the encryption data length determination in the same processing chain. Compared to processing directly according to network packets, this step provides a unified processing path for scenarios where encryption headers cross packets, encryption data cross packets, and multiple complete encryption data units enter continuously, ensuring stable input for subsequent encryption / decryption status identification.

[0183] Step S300 includes at least steps S310-S330:

[0184] S310. Obtain the complete unit verification record, perform encryption / decryption status identification and processing path registration processing, and obtain the status splitting record;

[0185] Specifically, the complete unit verification record comes from the preceding step S230. This record includes at least the boundary position of the complete encrypted data unit, its integrity verification status, start identifier, protocol version, encryption / decryption status, data length, and encrypted data length. Therefore, the input for this step already contains the minimum set required for status identification. The encryption / decryption status identification is performed by the agent program in the encryption gateway.

[0186] The agent program first reads the integrity verification status in the complete unit verification record, and only complete encrypted data units that pass the verification proceed to the subsequent identification process. For complete encrypted data units that fail the integrity verification, this step does not proceed to the pass-through processing, decryption processing, and key update data reading. Instead, it registers the complete unit verification record as an invalid unit record and waits for the next complete encrypted data unit in the receiving buffer to enter the new identification process.

[0187] Furthermore, the encryption / decryption status identification involves reading the encryption / decryption status field in the encryption header and mapping the read value to the status semantics pre-registered by the encryption gateway. The unencrypted state corresponds to pass-through processing, the encrypted state corresponds to decryption processing, and the key update state corresponds to key update data reading. The status semantics here are not ad-hoc judgments, but rather fixed identifications based on the status field interpretation rules corresponding to the protocol version after the protocol version is read. Therefore, the protocol version and encryption / decryption status jointly participate in path determination in this step.

[0188] Understandably, when the protocol version is version number one, the encryption gateway identifies the protocol version according to the state interpretation order corresponding to version number one. When other protocol versions exist subsequently, the order of reading the protocol version first, then reading the encryption / decryption state, and finally registering the path remains unchanged, without altering the main processing chain of this step. The path registration process is performed after state identification. The agent program writes the boundary location of the complete encrypted data unit, the encryption / decryption state, the protocol version, the data length, the encrypted data length, and the target processing path into the same record, forming a state routing record that is directly invoked in subsequent steps.

[0189] The target processing path in the state routing record includes at least a service server path and a key update path; the former is called by S320, and the latter, together with the uplink processing record of S320, is called by S330. Specifically, in engineering implementation, the acquisition terminal continuously sends complete encrypted data units. After the encryption gateway has completed the start identifier lookup and integrity verification in the receiving buffer, if the encryption / decryption status of a complete encrypted data unit is encrypted, this step registers the complete encrypted data unit to the service server path; if the encryption / decryption status of another complete encrypted data unit is key update, this step registers the complete encrypted data unit to the key update path.

[0190] Through the above processing, the agent program records the output field name of this step as "state splitting record" and uses this output field as a direct input for subsequent S320 calls. At the same time, the state splitting record is also used as one of the preceding inputs of S330 to participate in the downlink complete encrypted data unit construction process.

[0191] S320. Based on the state splitting record, perform pass-through processing and decryption processing to obtain the uplink processing record;

[0192] Specifically, after the state flow record enters this step, the proxy program in the encryption gateway first groups the state flow record according to the target processing path, and then calls the pass-through processing and decryption processing respectively. The pass-through processing corresponds to the unencrypted state.

[0193] The agent program extracts the payload location of the complete encrypted data unit from the state splitting record, truncates the corresponding data according to the data length registration content, and then sends the corresponding data to the business server through the communication module. This pass-through processing preserves the original payload order, does not perform security encryption chip decryption on the payload, and does not perform any recovery calculations on the encrypted data length.

[0194] The decryption process corresponds to the encryption state. The agent program extracts the encrypted data and data length from the state distribution record, and calls the current key to perform decryption processing on the encrypted data; after decryption, it extracts valid data from the decryption result according to the data length to form the uplink data sent to the business server.

[0195] The data length is used to indicate the range of valid data that should be retained, and the encrypted data length is used to indicate the complete reading range corresponding to the current encrypted data. Therefore, the decryption process is to first retrieve the encrypted data, then decrypt it, and finally restore the valid data according to the data length, instead of directly restoring all bytes in the receiving buffer.

[0196] Furthermore, in this step, the business server is the unified receiving end for uplink processing. Although the pass-through processing and the decryption processing follow different paths, they ultimately form uplink data that can be received by the business server, and are written into the same type of record by the agent program. This uplink processing record includes at least the complete encrypted data unit identifier, the target processing path, the data location sent to the business server, and the current processing status.

[0197] If the communication module is briefly interrupted during the pass-through process, the agent program retains the status split record and marks the processing status as pending transmission; if the current key is missing during the decryption process, the agent program retains the status split record for use in the S330's key update path and does not continue to send it in this step.

[0198] Understandably, the pass-through processing and decryption processing in this step are not substitutes for each other, but rather parallel candidate paths determined by the state splitting record; the agent program executes only one path for each state splitting record, but can continuously execute both types of processing for multiple state splitting records in the entire receive buffer.

[0199] In technical solution one, the encryption gateway immediately performs pass-through processing or decryption processing for each state diversion record formed.

[0200] In technical solution two, the encryption gateway first accumulates multiple state diversion records, and then processes them in batches according to the unencrypted state and the encrypted state respectively;

[0201] In technical solution three, the encrypted gateway processes the status diversion records from the same acquisition terminal serially in the order of arrival, and processes the status diversion records from different acquisition terminals in parallel.

[0202] All three technical solutions maintain the same input and output fields, differing only in the scheduling method of the proxy program. Through the above processing, the proxy program records the data results after transparent transmission and decryption as the output field name "Uplink Processing Record," and provides this output field for subsequent direct input calls by S330. Simultaneously, the uplink processing record corresponds to the business server path and is used for downlink valid data encryption and downlink complete encrypted data unit construction processing.

[0203] S330. Based on the state splitting record and the uplink processing record, perform key update data reading, valid data encryption and downlink complete encrypted data unit construction processing to obtain the downlink encrypted data unit record.

[0204] Specifically, the state routing record serves as the state entry point in this step, and the uplink processing record serves as the business data entry point. The proxy program first reads the target processing path from the state routing record to identify if a key update path exists corresponding to the key update state. When a key update path exists, the proxy program reads the current key and generates key update data according to the fixed key protection order. Here, the current key is the key content currently registered by the encryption gateway and used for decryption and encryption processing; the fixed key is the pre-registered protection key; and the key update data is the data sent after reading the current key. After the key update data is read, the proxy program does not send it directly but uses the same complete encrypted data unit construction rule as subsequent valid data encryption processing.

[0205] Furthermore, for business data entry points from the uplink processing record, the agent program extracts valid data returned by the business server from the uplink processing record, or extracts business data that needs to be sent to the acquisition terminal, and records the original length of the valid data; then, it calls the current key to encrypt the valid data to obtain encrypted data, and simultaneously records the length of the encrypted data. Here, the original length and the encrypted data length follow the field logic in the previous steps, the former representing the actual length of the valid data, and the latter representing the length after padding and encryption.

[0206] The construction and processing of the downlink complete encrypted data unit is executed uniformly in the key update path and the business data path. The proxy program first writes the start identifier and protocol version, then writes the encryption / decryption status; for key update data, it writes the key update status; for business data, it writes the encryption status. Then it writes the original length and the encrypted data length, sequentially concatenates the encrypted data, and appends a checksum to the end to form the downlink complete encrypted data unit.

[0207] Understandably, this step uses the same encryption header structure, encryption / decryption status field, and checksum field as S130, enabling the acquisition terminal to perform terminal reception and security encryption chip recovery processing according to the same structure in S410. Specifically, in an engineering embodiment, when a service server sends control data to an acquisition terminal, the proxy program retrieves the control data from the uplink processing record, records the original length, performs encryption processing, and then writes the start identifier, protocol version, encryption status, original length, encrypted data length, and checksum to form a corresponding complete downlink encrypted data unit. When another acquisition terminal needs to update its current key, the proxy program identifies the key update path from the status splitting record, reads the current key, generates key update data, and writes the start identifier, protocol version, key update status, original length, encrypted data length, and checksum to form another complete downlink encrypted data unit. Both types of data units enter the same transmission queue and are subsequently called by S410.

[0208] Through the above processing, the agent program records the output field name of this step as "downlink encrypted data unit record" and makes this output field available for subsequent S410 as direct input; this output field maintains a continuous correspondence with the terminal recovery record and multiplexing configuration record of S400, and also constitutes a direct connection from the entire uplink processing to the downlink multiplexing closed loop.

[0209] The key technical effect of this step is that it integrates key update data and valid data sent by the service server into the same construction chain for processing. This transforms the downlink transmission path from fragmented into independent message paths and independent key paths into a unified downlink complete encrypted data unit path. Compared to a structure that only processes uplink service data, this step connects state splitting records, uplink processing records, and downlink complete encrypted data unit construction processing onto the same processing chain, ensuring a unified input format for subsequent terminal reception and security encryption chip recovery.

[0210] Step S400 includes at least steps S410-S430:

[0211] S410. Obtain the downlink encrypted data unit record, perform terminal reception and security encryption chip recovery processing, and obtain the terminal recovery record;

[0212] Specifically, the downlink encrypted data unit record comes from the preceding step S330. The downlink encrypted data unit record includes at least a start identifier, protocol version, encryption / decryption status, data length, encrypted data length, encrypted data, and checksum. Therefore, the input of this step already has the set of fields required for terminal-side recovery processing.

[0213] The terminal reception is executed by the terminal device's main control chip through the communication module. The triggering conditions are that the communication module is in a connected state, there is a complete downlink encrypted data unit from the encryption gateway, and the terminal device's main control chip's read / write interface is in a callable state. After receiving the downlink byte stream, the terminal device's main control chip first registers the currently received content at the boundary position in the downlink encrypted data unit record, and then reads the start identifier, protocol version, encryption / decryption status, data length, encrypted data length, and checksum from the registration result to form a receiving field mapping on the terminal side.

[0214] The terminal reception here is not simply receiving packets, but rather receiving the entire downlink complete encrypted data unit as the object of recovery processing. Subsequent recovery processing by the security encryption chip revolves around the same downlink complete encrypted data unit.

[0215] Furthermore, the recovery process of the security encryption chip is completed in cooperation between the terminal device's main control chip and the security encryption chip. The terminal device's main control chip first extracts encrypted data from the downlink complete encrypted data unit according to the encrypted data length, and then writes the encrypted data to the security encryption chip through the write interface.

[0216] After receiving encrypted data, the security encryption chip performs recovery processing; when the encryption / decryption state corresponds to the encryption state, the security encryption chip decrypts the encrypted data and outputs the recovered original data; when the encryption / decryption state corresponds to the key update state, the security encryption chip recovers the key update data and outputs the updated content corresponding to the current key.

[0217] The terminal device's main control chip then reads the recovery result output by the security encryption chip through the read interface and truncates the valid data range based on the data length. Here, the data length is still used as the valid length field in the recovery process, and the encrypted data length is still used as the encrypted data reading range in the recovery process. Both maintain the same field meaning on the terminal side and the encryption gateway side.

[0218] If the terminal device's main control chip detects that the length of the encrypted data recorded in the downlink encrypted data unit is inconsistent with the actual received length, then the current round will not proceed with the security encryption chip writing action. Instead, the received content will be retained in the corresponding reception registration of the communication module and restored after complete reception.

[0219] If the security encryption chip returns a null value at the read interface, the terminal device's main control chip will register the record as a record to be recovered and retain the field content in the downlink encrypted data unit record.

[0220] Understandably, in technical solution one, the terminal device's main control chip immediately calls the security encryption chip to restore after receiving each complete downlink encrypted data unit; in technical solution two, the terminal device's main control chip first completes the reception of multiple complete downlink encrypted data units, and then calls the security encryption chip to restore in the order of arrival; in technical solution three, the terminal device's main control chip registers the service data and key update data separately, but uses the same write interface and read interface calling method for both.

[0221] Through the above processing, the terminal device's main control chip organizes the recovered original data or updated content, along with the corresponding protocol version, encryption / decryption status, data length, and encrypted data length, into an output field named "Terminal Recovery Record," and provides this output field for subsequent S420 as direct input. At the same time, the terminal recovery record maintains the field correspondence with the downlink complete encrypted data unit construction processing of the preceding S330, and subsequent multiplexing configuration updates continue to unfold around this record.

[0222] S420. Based on the terminal recovery record, perform protocol version reuse configuration and encryption / decryption status reuse configuration processing to obtain a reuse configuration record;

[0223] Specifically, after the terminal recovery record enters this step, the terminal device's main control chip first reads the protocol version and encryption / decryption status, then reads the corresponding original data, current key update content, data length, and encrypted data length, and enters the multiplexing configuration processing according to the recovery type. The protocol version multiplexing configuration refers to the terminal device's main control chip registering the protocol version used in this round of downlink recovery as a callable version for the next round of transmission paths. When the terminal device's main control chip detects that the protocol version in this round is consistent with the currently registered protocol version, it directly retains that protocol version as the callable version for subsequent S110. When the terminal device's main control chip detects that the protocol version in this round is inconsistent with the currently registered protocol version, it writes the protocol version in this round into the protocol configuration update area and retains the old version in the version registration area for comparison and calling. The version registration area here belongs to the protocol configuration registration content in the terminal device's main control chip; it does not change the original positions of the start identifier, data length, and checksum fields, but only updates the registration value corresponding to the protocol version.

[0224] Furthermore, the encryption / decryption state reuse configuration refers to the terminal device's main control chip writing the encryption / decryption state from the terminal recovery record back to the status field registration area of ​​the subsequent transmission path. If the current terminal recovery record corresponds to service data, the terminal device's main control chip reuses the encryption / decryption state as the current configuration of either the encrypted or unencrypted state; if the current terminal recovery record corresponds to key update data, the terminal device's main control chip, after writing the current key update content, registers the encryption / decryption state reused in the status field position corresponding to the key update state, while simultaneously retaining the status field content of the service data path. This reuse configuration processing is not a simple copy, but rather re-registers the protocol version and encryption / decryption state as components of the next round of original data and protocol configuration records, enabling S110 to directly call the configuration content output in this step when obtaining the original data, start identifier, and protocol version from the data source. In engineering implementation, this step can be automatically triggered by the terminal device's main control chip after each read interface completes reading, or it can be triggered synchronously when the service interface writes new original data. Once the current key update is registered in the configuration area corresponding to the status field, the original data subsequently sent to the security encryption chip via the write interface will still use the same protocol version and the same status field position, without the need to construct new status semantics on the terminal side.

[0225] Through the above processing, the terminal device's main control chip organizes the protocol version registration result, encryption / decryption status registration result, and corresponding recovery type into an output field named "Reuse Configuration Record," and provides this output field for subsequent S430 as a direct input. At the same time, the reuse configuration record is directly associated with the original data and protocol configuration record in S100, forming the configuration basis for the next round of collection and registration processing.

[0226] S430. Based on the reuse configuration record, perform data length update and check value update processing to obtain the updated original data and protocol configuration record;

[0227] Specifically, after the multiplexing configuration record enters this step, the terminal device's main control chip first reads the field contents corresponding to the protocol version multiplexing configuration and the encryption / decryption status multiplexing configuration. Then, it extracts the original data, current key update content, data length, and encrypted data length from the associated fields of the terminal recovery record and performs data length update processing. The data length update processing includes two paths: First, when the multiplexing configuration record corresponds to business data, the terminal device's main control chip writes the original data length from the terminal recovery record back to the original data length registration area and writes the encrypted data length back to the encrypted data length registration area, serving as the direct length source for the next round of encryption processing. Second, when the multiplexing configuration record corresponds to key update data, the terminal device's main control chip writes the length corresponding to the current key update content into the data length registration area and writes the encrypted data range formed by the update content into the encrypted data length registration area, thus ensuring that the next round of data transmission path after the key update remains consistent with the current round of recovery path. Here, the data length update processing adopts a reverse write-back method for the terminal recovery result. The updated fields are not stored in isolation but rather, together with the protocol version, encryption / decryption status, and start identifier, form a new protocol configuration basis.

[0228] Furthermore, after completing the data length update, the terminal device's main control chip performs a checksum update process. This checksum update process involves re-registering the checksums of the updated original data and protocol configuration content. Specifically, the terminal device's main control chip generates the checksum registration content to be called in the next round of transmission paths according to the order of the starting identifier, protocol version, encryption / decryption status, data length, encrypted data length, and currently valid data, and writes this checksum to the checksum location configured in the protocol. This checksum update does not directly form a new downlink complete encrypted data unit, but rather forms the pre-registered field content called in subsequent steps S110 and S130. If the reuse configuration record only updates the protocol version without updating the original data, the terminal device's main control chip retains the data length registration result from the previous round and only updates the corresponding checksum registration content. If the reuse configuration record updates both the encryption / decryption status and the current key update content, the terminal device's main control chip synchronously updates the data length and checksum content, and retains the old checksum in the historical registration area for the terminal to read from the log system.

[0229] Understandably, the automation level of this step is reflected in the following: the terminal device's main control chip automatically triggers data length and checksum updates upon receiving the reused configuration record, without relying on manual configuration; the version management strategy is reflected in the following: updates to the protocol version, encryption / decryption status, data length, and checksum are all written into traceable registration content, with old and new configurations retained in parallel. Subsequent S110 calls read the latest registration content, and the old configuration content can still be read in case of abnormal rollback. In this way, a continuously updated link between raw data and protocol configuration is formed on the terminal side during project operation.

[0230] Through the above processing, the terminal device main control chip records the output field name of this step as "updated original data and protocol configuration record", and sends the output field back to the input path of subsequent S110 as the direct call content when obtaining the original data, start identifier and protocol version of the data source; at the same time, the updated original data and protocol configuration record forms a complete closed loop with the field links of S100, S200 and S300.

[0231] The key technical effect of this step is that it directly writes back the recovered protocol version, encryption / decryption status, data length, and checksum as the protocol configuration content for the next round of transmission, ensuring that the terminal's receiving and transmitting paths use the same field structure. Compared to methods that only complete downlink recovery without updating the configuration, this step connects terminal reception, security encryption chip recovery, protocol version reuse configuration, encryption / decryption status reuse configuration, data length update, and checksum update into a continuously running closed-loop link. In the next round, S110 can directly call the updated original data and protocol configuration records.

[0232] Example 2: Figure 2 A structural block diagram of a data source-based security chip encryption design method according to an embodiment of the present invention is shown. Figure 2 As shown, the structure may include:

[0233] The acquisition and registration module 01 is used to obtain the raw data, starting identifier, and protocol version from the data source, perform acquisition and registration processing, and obtain raw data and protocol configuration records. Specifically, the acquisition and registration module receives raw data from the data source and reads the starting identifier and protocol version from the local protocol configuration area. The data source is provided by the service interface connected to the main control chip of the terminal device, and the raw data is written to the acquisition cache in the order of reception. The acquisition and registration module starts processing when the communication module is online and there is raw data to be sent. First, the length of the raw data is registered, and then the starting identifier and protocol version are established to correspond with the current raw data to form the same registration content. The acquisition and registration processing includes four types of actions: raw data reception, field correspondence, sequential registration, and exception retention. When the raw data is empty, only the starting identifier and protocol version are retained in this round and not sent to the next round. When the starting identifier or protocol version is not read, the acquisition and registration module calls the protocol configuration content saved in the previous round to fill in the current registration content. The original data and protocol configuration record are written into the registration area as the output object of this segment, and are provided to the security encryption chip processing module for writing via the write interface, encryption via the security encryption chip, and reading via the read interface.

[0234] The secure encryption chip processing module 02, connected to the acquisition and registration module, is used to perform write interface writing, secure encryption chip encryption, and read interface reading based on the original data and protocol configuration record, to obtain encrypted data and a length record. Specifically, the secure encryption chip processing module receives the original data and protocol configuration record output from the acquisition and registration module, and extracts the original data, start identifier, and protocol version from the original data and protocol configuration record. The secure encryption chip processing module first sends the original data to the secure encryption chip through the write interface, then the secure encryption chip performs encryption processing on the original data, and returns the encrypted data through the read interface. The write interface and read interface are connected to the main control chip of the terminal device, and both writing and reading are performed in the registration order of the original data. The secure encryption chip processing module synchronously registers the data length and encrypted data length during the read interface reading process, where the data length corresponds to the effective length of the original data, and the encrypted data length corresponds to the length after padding and encryption processing. The secure encryption chip processing module registers abnormal states for cases where the write interface is incomplete, the read interface does not return, the encrypted data is empty, and the length field is missing, and retains the current original data and protocol configuration record for rereading. The encrypted data and length record are written into the length record area as the output object of this segment, and the encrypted data and length record are provided to the complete encrypted data unit construction module for encryption header writing, encryption / decryption status writing and verification value appending processing calls.

[0235] A complete encrypted data unit construction module 03, connected to the secure encryption chip processing module, is used to perform encryption header writing, encryption / decryption status writing, and checksum appending processing based on the encrypted data and length record to obtain a complete encrypted data unit. Specifically, the complete encrypted data unit construction module receives the encrypted data and length record from the secure encryption chip processing module and calls the start identifier and protocol version from the corresponding original data and protocol configuration record. The complete encrypted data unit construction module first writes the encryption header, then writes the encryption / decryption status, then concatenates the encrypted data, and finally appends the checksum to form a continuous complete encrypted data unit. The encryption header at least includes a start identifier, protocol version, encryption / decryption status, data length, and encrypted data length; the encryption / decryption status is registered according to the business data path and key update path respectively; the checksum is generated according to the continuous content from the start identifier to the end of the encrypted data. The complete encrypted data unit construction module stops concatenating when the encryption header field is missing, the encryption / decryption status is not registered, or the checksum is not generated, and retains the current encrypted data and length record to wait for completion. The complete encrypted data unit is written into the sending queue as the output object of this segment and is called by the receiving buffer unit extraction module as a complete encrypted data unit. At the same time, the complete encrypted data unit retains the field order information in the local construction record for subsequent receiving buffer writing, start identifier lookup and encryption header reading processing.

[0236] The receive buffer unit extraction module 04, connected to the complete encrypted data unit construction module, is used to acquire the complete encrypted data unit, perform transmission control protocol sending, receive buffer writing, start identifier lookup, encryption header reading, encrypted data length judgment, and integrity verification processing to obtain a complete unit verification record. Specifically, the receive buffer unit extraction module acquires the complete encrypted data unit output from the complete encrypted data unit construction module and sends it to the encryption gateway through the communication module. After receiving the complete encrypted data unit, the encryption gateway-side agent program first writes it into the receive buffer, and then sequentially performs start identifier lookup and encryption header reading processing from the receive buffer. The start identifier lookup starts scanning from the current reading position in the receive buffer; when the start identifier is found, the protocol version, encryption / decryption status, data length, and encrypted data length are read; then, the encryption data length and verification value length are used to determine whether a complete unit has been formed in the current receive buffer; when a complete unit is formed, integrity verification is performed on the continuous content from the start identifier to the end of the encrypted data. The receive buffer unit extraction module uniformly retains the cases of start identifier cross-packet, encryption header cross-packet, encrypted data cross-packet, and multiple complete encrypted data units entering consecutively in the receive buffer, without directly deleting incomplete data. The complete unit verification record is written into the verification record area as the output object of this segment, and is provided to the encryption / decryption status splitting processing module for encryption / decryption status identification, processing path registration, pass-through processing, and decryption processing invocation.

[0237] The encryption / decryption status splitting processing module 05, connected to the receiving buffer unit extraction module, is used to acquire the complete unit verification record, perform encryption / decryption status identification, processing path registration, transparent transmission processing, and decryption processing to obtain the uplink processing record. It also performs key update data reading, valid data encryption, and downlink complete encrypted data unit construction processing to obtain the downlink encrypted data unit record. Specifically, the encryption / decryption status splitting processing module receives the complete unit verification record output from the receiving buffer unit extraction module, first reads the integrity verification status, and then reads the encryption / decryption status. The encryption / decryption status splitting processing module only processes complete unit verification records that pass integrity verification; for records that fail integrity verification, it registers an invalid status and returns to the receiving buffer to wait for the next record. After the encryption / decryption status identification is completed, the encryption / decryption status splitting processing module registers the processing path according to the unencrypted state, encrypted state, and key update state. For the unencrypted state, the encryption / decryption status splitting processing module extracts the payload and sends it to the service server to form a transparent transmission processing result. In the encrypted state, the encryption / decryption state splitting processing module calls the current key to decrypt the encrypted data, truncates the valid data according to the data length, and then sends it to the business server to form the decryption processing result. In the key update state, the encryption / decryption state splitting processing module reads the current key and registers the key update data. After obtaining the uplink processing record, the encryption / decryption state splitting processing module performs encryption processing on the valid data from the business server, registers the original length and the encrypted data length, and then constructs the downlink complete encrypted data unit according to the field order of the complete encrypted data unit. The uplink processing record is written to the uplink record area, the downlink encrypted data unit record is written to the downlink record area, and the downlink encrypted data unit record is provided to the downlink unit multiplexing configuration module for terminal reception and security encryption chip recovery processing.

[0238] Downlink unit multiplexing configuration module 06, connected to the encryption / decryption status splitting processing module, is used to acquire the downlink encrypted data unit record, perform terminal reception and security encryption chip recovery processing to obtain a terminal recovery record, and based on the terminal recovery record, perform protocol version multiplexing configuration, encryption / decryption status multiplexing configuration, data length update, and checksum update processing to obtain the updated original data and protocol configuration record. Specifically, the downlink unit multiplexing configuration module receives the downlink encrypted data unit record output from the encryption / decryption status splitting processing module, and the terminal device main control chip completes terminal reception through the communication module. After receiving the downlink encrypted data unit record, the terminal device main control chip first reads the start identifier, protocol version, encryption / decryption status, data length, encrypted data length, encrypted data, and checksum according to the field boundaries, and then writes the encrypted data to the security encryption chip through the write interface. After the security encryption chip completes the recovery processing, the terminal device main control chip reads the recovery result through the read interface and extracts valid data according to the data length to form the terminal recovery record. The downlink unit multiplexing configuration module then reads the protocol version and encryption / decryption status from the terminal recovery record, and performs protocol version multiplexing configuration and encryption / decryption status multiplexing configuration. It then reads the data length and encrypted data length from the terminal recovery record, and performs data length update and checksum update processing. The results of the protocol version multiplexing configuration, encryption / decryption status multiplexing configuration, data length update, and checksum update processing are summarized into the updated original data and protocol configuration record and written to the configuration update area. The updated original data and protocol configuration record serves as the output object of this segment, for use in the next round of original data processing, while retaining the terminal recovery record for status tracking in the current round.

Claims

1. A secure chip encryption design method based on a data source, characterized in that, include: S100: Obtain the raw data, starting identifier, and protocol version from the data source; perform data collection and registration processing; and encrypt the data using a security encryption chip to obtain a complete encrypted data unit. The data source is provided by the data acquisition module in the acquisition terminal or the service interface connected to the main control chip of the terminal device; the raw data is the acquired data that has not yet entered the security encryption chip for processing; the start identifier is the magic number subsequently written into the encryption header; and the protocol version is the version number subsequently written into the encryption header. S200. Based on the complete encrypted data unit, perform TCP sending processing and receiving buffer writing processing to obtain the complete unit verification record; S300. Based on the complete unit verification record, perform encryption / decryption status splitting and uplink processing to obtain downlink encrypted data unit records. S400. Based on the downlink encrypted data unit record, perform terminal reception processing, security encryption chip recovery processing, and reuse configuration update processing to obtain the updated original data and protocol configuration record.

2. The method according to claim 1, characterized in that, The process of data collection, registration, and processing includes: The data collection and registration process includes: registering the original data, starting identifier, and protocol version in the main control chip of the terminal device, and retaining the registration results without entering the encryption path of the security encryption chip when the communication module is interrupted.

3. The method according to claim 2, characterized in that, The encryption process of a secure encryption chip includes: The original data is written to the security encryption chip through the write interface, and the security encryption chip performs padding and encryption. Then, the encrypted data is output to the main control chip of the terminal device through the read interface, and the data length and encrypted data length corresponding to the encrypted data are read simultaneously. The data length represents the effective length of the original data, and the encrypted data length represents the length after padding and encryption by the security encryption chip.

4. The method according to claim 3, characterized in that, The process of obtaining a complete encrypted data unit includes: The process of obtaining a complete encrypted data unit includes: performing encryption header writing, encryption / decryption status writing, and verification value appending processing in the main control chip of the terminal device; The encryption header writing includes: sequentially writing the start identifier, protocol version, encryption / decryption status, data length, and encrypted data length, wherein the encryption / decryption status field reserves three values ​​in the same position: unencrypted state, encrypted state, and key update state; The verification value appending process includes: performing verification calculations on the continuous content from the start identifier to the end of the encrypted data and appending the verification result to the encrypted data to obtain a complete encrypted data unit consisting of an encryption header, encrypted data, and a verification value.

5. The method according to claim 4, characterized in that, The process of writing to the receive buffer includes: The encrypted gateway continuously appends the TCP byte stream to the receive buffer and records the current write position and the current data volume. Bytes that were not read in the previous round are retained together with the newly received bytes.

6. The method according to claim 5, characterized in that, The process of obtaining a complete cell verification record includes: The process of obtaining a complete unit verification record includes: performing a start identifier lookup and encryption header reading in the receiving buffer to obtain an encryption header positioning record containing the start identifier position, protocol version, encryption / decryption status, data length, and encrypted data length; Based on the length of encrypted data in the encrypted header location record, determine whether all bytes required for a complete encrypted data unit have been received from the starting identifier position. When the readable length is insufficient, retain the encrypted header location record and wait for subsequent TCP writes before making another judgment; When the readable length is reached, the continuous content from the start identifier position to the end of the encrypted data is truncated, the check value is recalculated, and compared with the received check value to obtain a complete unit check record containing the boundary position, integrity check status and encryption header field.

7. The method according to claim 6, characterized in that, The encryption / decryption state splitting process includes: Read the encryption / decryption status field from the complete unit verification record, and assign the unencrypted status to the pass-through processing path, the encrypted status to the decryption processing path, and the key update status to the key update data reading path.

8. The method according to claim 7, characterized in that, The process of obtaining the downlink encrypted data unit record through the uplink processing includes: The uplink processing includes: transparently transmitting unencrypted data, and decrypting and extracting valid data from encrypted data based on the data length and the encrypted data length. The process of obtaining the downlink encrypted data unit record includes: writing the start identifier, protocol version, encryption / decryption status, data length, encrypted data length, and appending a check value to the data returned by the service server or the key update data, thereby obtaining the downlink encrypted data unit record.

9. The method according to claim 8, characterized in that, The terminal receiving and processing process includes: The terminal device's main control chip reads the start identifier, protocol version, encryption / decryption status, data length, encrypted data length, and checksum from the downlink encrypted data unit record.

10. The method according to claim 9, characterized in that, The process of recovering and reusing the security encryption chip and updating its configuration includes: The security encryption chip recovery process includes: the terminal device's main control chip extracts encrypted data according to the encrypted data length and writes it into the security encryption chip, and reads the recovery result through the read interface, and truncates the valid data range according to the data length; The reuse configuration update process includes: writing the protocol version and encryption / decryption status from the terminal recovery record back to the configuration registration area of ​​the next round of transmission path, and updating the data length and encrypted data length to obtain the updated original data and protocol configuration record written back to the collection registration process.

Images