A secure data packet generation method with file header signature separated from data body signature

Abstract

The application discloses a kind of file header signature and data body signature separate security data packet generation method, it is related to information security technical field, including the following steps: after generating first private key and second private key are group transformation, obtain first, second verification public key;Using session key and first private key encrypts original file and signs, obtains data body and data body signature;Cascading hash is carried out to file header and data body, and generates context binding value;After splicing first, second verification public key and context binding value, calculate digest value and map into the nonlinear constraint coefficient in scalar field;Using the constraint coefficient is weighted to the coordinate point obtained by the binding value calculation, using second private key is signed to the weighted result, generates file header signature;Encapsulate file header, data body, file header signature, data body signature generates security data packet.The application is used to solve the problem that data packet component is easily replaced and tampered under the separation architecture of header and body, and signature is vulnerable to key offset attack.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and more specifically, to a method for generating secure data packets that separates the header signature from the data body signature. Background Technology

[0002] The current large file transfer generally adopts the "header-body separation" mechanism to improve processing efficiency. This layered processing weakens the integrity of the file structure and puts forward higher requirements for data consistency and security binding.

[0003] For example, a data signature method in patent application CN116545631A obtains a target signature by linearly aggregating the initial signature results from multiple terminals, achieving unified authentication among multiple parties and reducing the size of the signature data. Another example is a collaborative signature method and related apparatus in patent application CN120110680A, which generates a target signature through multiple interactions and collaborative calculations between a mobile terminal and collaborating terminals, and enhances the security of the private key through key fragmentation.

[0004] However, when the above-disclosed technical solutions are applied to high-concurrency secure transmission scenarios involving "head-body separation," at least the following technical problems exist:

[0005] 1. Existing linear aggregation signature schemes typically focus on signing and compressing individual data blocks, often lacking cryptographic constraints for hierarchical structures. The correlation between keys is relatively limited, making it difficult to guarantee the consistency of the overall data and thus failing to meet the encapsulation requirements of high-level data.

[0006] 2. Existing multi-party collaboration solutions typically rely on multiple rounds of online interaction between multiple entities, resulting in high communication latency. This limits the efficiency of data packet generation and transmission in low-bandwidth or high-concurrency scenarios.

[0007] Therefore, there is an urgent need for a secure data packet generation method that integrates header and body structural features and strongly binds signature aggregation with data structure, in order to solve the problems of missing component binding, limited interaction efficiency, and vulnerability of signatures to key cancellation attacks in existing technologies. Summary of the Invention

[0008] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a secure data packet generation method that separates the header signature from the data body signature. By calculating the context binding value based on the concatenation relationship between the header and the data body, and using nonlinear constraint coefficients for weighted modulation, the method solves the technical problems of data packet components being easily replaced and tampered with under the existing header-body separation architecture, and the signature being vulnerable to key cancellation attacks.

[0009] To achieve the above objectives, the present invention provides the following technical solution:

[0010] A method for generating secure data packets by separating header signature from data body signature includes the following steps:

[0011] Randomly generate a first private key and a second private key, and perform a group transformation to obtain a first verification public key and a second verification public key;

[0012] The initial file is encrypted and signed using the session key and the first private key to obtain the data body and the data body signature;

[0013] Perform a concatenated hash operation on the file header and data body containing the session key ciphertext to generate a context binding value;

[0014] The digest value is calculated by concatenating the first verification public key, the second verification public key, and the binding value. Based on the preset elliptic curve parameters, the digest value is mapped to a nonlinear constraint coefficient in a preset scalar domain.

[0015] The binding value is weighted using the constraint coefficients, and the weighted result is signed using the second private key to obtain the file header signature;

[0016] Encapsulate the file header, data body, data body signature, and file header signature to generate a secure data packet.

[0017] In a preferred embodiment, the preset elliptic curve parameters include at least the group order value and prime field modulus of the preset elliptic curve, and the step of mapping the obtained summary value to nonlinear constraint coefficients in a preset scalar field includes: using the calculated summary value to perform a modulo operation on the group order value of the preset elliptic curve to obtain nonlinear constraint coefficients in the scalar field, wherein the scalar field is a set of integers with the group order value as the modulus.

[0018] In a preferred embodiment, obtaining the file header signature includes: based on the prime field modulus, performing modulo reduction on the context binding value and solving the curve equation of a preset elliptic curve to obtain coordinate points on the elliptic curve; using nonlinear constraint coefficients as weighting factors, performing scalar multiplication on the coordinate points to obtain weighted modulation points; and signing the weighted modulation points using a second private key to obtain the file header signature.

[0019] In a preferred embodiment, obtaining the data body includes: extracting the directory structure information and file content data of the original file, and encrypting them respectively using a preset session key to obtain a structure stream and an encrypted file stream; concatenating the structure stream and the encrypted file stream to generate the data body.

[0020] In a preferred embodiment, the encapsulation of the file header, data body, data body signature, and file header signature includes: performing point addition on the data body signature and the file header signature based on the additive homomorphic property of elliptic curves to generate a single global aggregate signature; and encapsulating the file header, data body, and the single global aggregate signature according to a preset structure to obtain a secure data packet.

[0021] In a preferred embodiment, obtaining the first verification public key and the second verification public key includes: randomly generating a first private key for signing the data body and a second private key for signing the file header and context binding relationship within an integer field defined by a preset elliptic curve group order value; and performing scalar multiplication operations on the first private key and the second private key respectively using the base point parameters of the preset elliptic curve to obtain the corresponding first verification public key and second verification public key characterizing the mathematical features of the private key.

[0022] In a preferred embodiment, the session key ciphertext is obtained by encrypting the session key with a pre-stored local encryption public key, and includes a key ciphertext digest value and a ciphertext data component obtained by XORing the session key.

[0023] A secure data packet communication system includes a sender and a receiver;

[0024] The sending end is used to execute the secure data packet generation method that separates the file header signature from the data body signature, generate a secure data packet, and send it; the receiving end is used to receive the secure data packet and perform integrity verification on the secure data packet based on a pre-established bilinear pair aggregation check equation.

[0025] In a preferred embodiment, the bilinear pair aggregation verification equation is as follows:

[0026]

[0027] in, This represents the bilinear pairing operation. For a single global aggregate signature in a secure data packet. To preset the base point parameters of the elliptic curve, The weighted modulation points are reconstructed at the receiving end. , These are the first verification public key and the second verification public key, respectively. The data body mapping point is specifically the coordinate point obtained by the receiving end through hashing the data body and mapping the result to a preset elliptic curve.

[0028] The technical effects and advantages of the secure data packet generation method that separates the header signature and the data body signature of the present invention are as follows:

[0029] 1. This invention generates a context binding value representing the relationship between the data body and the file header containing the encrypted session key by performing a concatenated hash operation on the data body and the file header. This context binding value is used as the basis data for the second private key signature. While retaining the advantages of the "header-body separation" architecture for streaming processing, it establishes a cryptographic dependency relationship between the file header and the data body, effectively avoiding file header replacement or data body splicing and tampering using the separation architecture, and ensuring the structural integrity and consistency of each component in the process of generating secure data packets.

[0030] 2. This invention obtains nonlinear constraint coefficients by mapping the first verification public key, the second verification public key, and the context binding value to a preset scalar domain, and then uses the nonlinear constraint coefficients to perform weighted modulation on the coordinate points derived from the context binding value, thereby generating a file header signature. In the signature construction process, nonlinear constraints based on key identity and data content are introduced, which reduces the risk of signature cancellation caused by algebraic homomorphism, improves the ability of secure data packets to resist malicious public key forgery and replay attacks during the generation stage, and meets the strict requirements of data encapsulation. Attached Figure Description

[0031] Figure 1 This is a schematic flowchart of a secure data packet generation method that separates the header signature and the data body signature, provided in an embodiment of the present invention.

[0032] Figure 2 This is a schematic diagram illustrating the sensitivity of the context binding value to file header tampering, as provided in an embodiment of the present invention.

[0033] Figure 3 This is a schematic diagram of the geometric principle of a single global aggregate signature provided in an embodiment of the present invention.

[0034] Figure 4 This is a schematic diagram comparing the bandwidth usage of communication transmission provided in an embodiment of the present invention. Detailed Implementation

[0035] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0036] Example 1, Figure 1 This invention provides a secure data packet generation method that separates the header signature from the data body signature, comprising the following steps:

[0037] S1. Randomly generate a first private key and a second private key, and perform a group transformation to obtain the corresponding first verification public key and second verification public key, including:

[0038] S101. Obtain the system parameters of the preset elliptic curve, including the base point parameters and group order value, as follows:

[0039] Elliptic curves conforming to national commercial cryptography standards, such as the BN-type curves used in the SM9 identifier cryptography algorithm, are adopted. Based on the 256-bit BN curve parameter set defined in "GM / T0044-2016 SM9 Identifier Cryptography Algorithm," the system parameters of the elliptic curve are directly set. Specifically, by retrieving the standard parameter set preset in the security chip or configuration file, the prime field modulus used to define the size of the finite field, and the irreducible polynomial parameters (including the imaginary unit parameter required for the tower construction) used to determine the quadratic and twelfth-order extension field structures are directly read. The twelfth-order extension field is implemented through a nested quadratic extension field and its upper-level sixth-order extension field. All irreducible polynomial parameters adopt the default configuration recommended in the standard document to ensure cross-platform interoperability. The system's computational environment is configured to adapt to the standard-defined first additive cyclic group located on the base domain, the second additive cyclic group located on the twisted line of the second extension domain, and the target multiplicative cyclic group located on the twelfth extension domain, and the prime group order value common to each cyclic group is loaded. Simultaneously, the non-degenerate bilinear pairing mapping function (such as the R-ate pairing function or the optimal Ate pairing function) preset in the standard algorithm library is called, and the generator coordinate data of the first additive cyclic group and the generator coordinate data of the second additive cyclic group are directly extracted from the standard parameter set and then set as the system's bi-base point parameters.

[0040] S102. Within the integer field defined by the preset elliptic curve group order value, a random number generation algorithm is used to generate the first private key and the second private key, as follows:

[0041] A high-entropy data segment (e.g., 256 bits) is collected from a hardware noise source or the operating system kernel entropy pool (such as the / dev / urandom interface in Linux) as the initial entropy input. Combined with an optional personalized string (such as the current timestamp or device ID), a random number generator conforming to the GM / T0005 standard (e.g., HMAC-DRBG based on the SM3 algorithm) is instantiated and initialized. The instantiated random number generator is then called to generate two sets of pseudo-random binary sequences with the same bit length as the group order value (e.g., 256 bits). Each set of pseudo-random binary sequences is converted into a large integer form and modulo operation is performed on the group order value to ensure that the generated values ​​strictly fall within the positive integer range defined by the group order value.

[0042] The two large integers after the modulo operation are defined as the first private key and the second private key, respectively. The first private key is used to sign the data body at the file content level to ensure the authenticity of the data content. The second private key is used to sign the file header and context binding relationship to ensure the integrity of the data packet structure.

[0043] S103. Using the base point parameters of a preset elliptic curve, perform scalar multiplication on the first private key and the second private key respectively to obtain the corresponding first verification public key and second verification public key that characterize the mathematical features of the private key, as follows:

[0044] Using the generator of the second additive cyclic group located on the twisted line of the quadratic extension field as the common base point, and employing a double-addition algorithm based on binary expansion, the first and second private keys are used to perform geometric transformations on the common base point based on the quadratic extension field to obtain the corresponding first and second verification public keys. The specific steps include: first, converting the private key from decimal large integer form to binary vector form, and setting a temporary point with an initial state of infinity on the elliptic curve; then, traversing from the most significant bit to the least significant bit of the binary vector, and performing the following geometric operations on each binary bit:

[0045] (1) Perform a doubling operation on the temporary point by calculating the intersection of the tangent line passing through the current temporary point and the twisted elliptic curve on the quadratic extended domain, and taking the symmetric point of the intersection point about the X-axis. The symmetric point is the temporary point after doubling. Algebraically, let the temporary point before the operation be... The coordinates are Double the amount and then add temporary points The calculation formula is:

[0046] ,

[0047] ,

[0048] ,

[0049] in, The slope of the tangent line. , These are temporary points before the operation. x and y coordinates , Temporary points after doubling The horizontal and vertical coordinates; the addition, subtraction, multiplication, division, and squaring operations in the formula for calculating the temporary point after doubling are all defined in the quadratic extended domain. Above, following the rules of polynomial modular arithmetic, the coordinates of the temporary point are located on the quadratic extended domain;

[0050] (2) Determine the value of the current binary bit: If the value is 0, skip this step and take the doubled temporary point obtained in step (1) as the final temporary point of the current binary bit output, and directly enter the next round of binary bit geometric operation; if the value is 1, on the basis of step (1), further perform point addition operation, calculate the intersection of the secant between the doubled temporary point and the common base point and the twisted elliptic curve, and take the symmetrical point of the intersection point about the X-axis as the final temporary point after performing point addition operation; algebraically, let the coordinates of the common base point be for Then the final temporary point The calculation formula is:

[0051] ,

[0052] ,

[0053] ,

[0054] in, The slope of the secant. , These are the coordinates of the common base point. x and y coordinates , These are the x and y coordinates of the final temporary point, respectively; the calculation formula for the final temporary point also operates within the quadratic extended domain. The execution is performed within the domain, and the final coordinate point lies on the secondary extended domain;

[0055] Finally, after all binary bits have been traversed, the final temporary point obtained is the corresponding verification public key containing the mathematical characteristics of the private key; the first verification public key and the second verification public key are both coordinate points on the second addition cyclic group, and will be sent to the receiving end as public parameters.

[0056] It should be noted that in the engineering implementation involving the addition and doubling of points on elliptic curves, this embodiment uniformly adopts the Jacobian weighted projective coordinate system for calculation to avoid high-frequency finite field inversion operations and improve processing efficiency. Temporary variables and final coordinate mappings in each calculation step are executed according to the standard formulas under this coordinate system.

[0057] S2. Encrypt and sign the original file using the session key and the first private key to obtain the data body and the data body signature;

[0058] In this embodiment, the data body obtained in step S2 includes:

[0059] S201. Extract the directory structure information and file content data of the original file, and encrypt them respectively using a preset session key to obtain a structure stream and an encrypted file stream, as follows:

[0060] The system reads the original file to be transmitted through the operating system's file system interface, parses and extracts the directory structure information and file content data; it then serializes the directory structure information using standardized encoding rules (such as TLV encoding format or ASN.1DER encoding format) to generate a unique binary byte sequence. The directory structure information includes file metadata, such as filename, relative path, file access permissions (such as read / write attributes), file creation timestamp, and total file size. The file content data is the directly extracted binary entity stream of the original file. Finally, it uses a lossless compression algorithm (such as Zlib or LZ77 algorithm) to independently compress the directory structure information and file content data, obtaining compressed structure data and compressed content data to reduce the data throughput and transmission bandwidth consumption of subsequent encryption operations.

[0061] The system calls the unified key management interface. If it detects the existence of an external high-entropy random source (such as a quantum key distribution (QKD) device) that is online, and further detects that the various indicators of the QKD key pool meet the preset thresholds (e.g., the number of available key groups with a key length of 256 bits is greater than 50), it directly reads a 256-bit (i.e., 32-byte) truly random quantum sequence from the quantum key pool through the hardware interface as the session key. If it detects that the external source does not exist, the link is interrupted, the device is offline, or the QKD resources do not meet the preset thresholds, it automatically calls the cryptographically secure pseudo-random number generator (such as / dev / urandom under Linux or the random source interface of the national cryptographic standard) to directly obtain a 256-bit high-strength pseudo-random binary sequence as the session key.

[0062] Using the session key, combined with the SM4 block cipher algorithm configured in counter mode or output feedback mode, the compressed structure data and compressed content data are encrypted respectively to obtain the ciphertext structure stream and encrypted file stream, thereby achieving covert protection of file attributes and content.

[0063] S202. Concatenate the structure stream with the encrypted file stream to obtain a data body, as follows:

[0064] Based on a preset topological order, the structure stream and the encrypted file stream are concatenated in binary to obtain a data body. The concatenation order can be preset to "structure stream first, encrypted file stream second" so that the receiving end can prioritize parsing the directory structure information at the header when performing streaming decryption. This allows for the pre-establishment of a file index or directory tree locally before the massive file content data arrives, thereby improving processing efficiency.

[0065] S203. Sign the data body using the first private key to generate a data body signature, as follows:

[0066] A cryptographic hash algorithm (such as SM3 or SHA-256) is used to perform a hash operation on the data body. The calculation formula is as follows:

[0067] ,

[0068] in, This represents a hash function with an output length of 256 bits. The data body; The generated message digest, the digest Essentially, it is a large integer representing the digital fingerprint of the data content;

[0069] A trial-and-error incremental hash mapping algorithm is used to map the message digest value onto the first additive cyclic group to obtain the message mapping point. The specific process is as follows: First, a modulo reduction operation based on the prime field modulus is performed on the message digest value of the corresponding length (e.g., 256 bits). The remainders falling within the prime field are used as candidate values ​​for the horizontal coordinate of the message mapping point. The theoretical ordinate square value corresponding to the candidate horizontal coordinate is calculated based on the curve equation of a preset elliptic curve. Next, based on a number theory criterion (e.g., Euler's criterion), a secondary remainder determination operation is performed on the theoretical ordinate square value, i.e., checking whether the theoretical ordinate square value has a corresponding integer square root in the prime field of the elliptic curve. If it does, it indicates that the candidate horizontal coordinate value lies on the first additive cyclic group. The corresponding ordinate value is calculated using a modular square root algorithm (such as the Tonelli-Shanks algorithm) to obtain a valid coordinate point, i.e., the message mapping point. If it does not exist, it means that the candidate value of the horizontal coordinate is not on the elliptic curve. Then, a preset incremental operation (e.g., adding 1 to the value) is performed on the candidate value of the horizontal coordinate, and a modulo reduction based on the prime field modulus is performed again. The result of the modulo reduction operation is then used as the new horizontal coordinate value, and the calculation of the theoretical square value of the ordinate and the second-order residue judgment steps are repeated until a valid coordinate point that satisfies the equation of the first addition cyclic group curve is found or the preset maximum number of incremental attempts is reached (e.g., 256 times). If all attempts fail, an abnormal interruption signal is output, and the input data stream is changed by regenerating the session key, thereby restarting the secure data packet generation process.

[0070] An elliptic curve scalar multiplication operation, logically isomorphic to step S103, is performed on the first private key and the message mapping point. The result is the data body signature. In this operation, the message mapping point acts as the common base point in step S103. It should be noted that, unlike step S103 which operates on a quadratic extended field, the domain of operation for the data body signature in this step is the base field (prime field). That is, the coordinate points and intermediate variables involved in the operation are all large integers on the base field. The final generated data body signature is essentially a geometric coordinate point on the first additive cyclic group.

[0071] This step reduces the data processing throughput of subsequent encryption operations by separating and compressing the directory structure and file content, and encrypting them using the session key and the first private key. It improves the processing efficiency and response speed under large data transmission, provides source authentication and integrity verification support for data packets, and thus reduces the risk of data being illegally tampered with or replaced during transmission.

[0072] S3. Perform a concatenated hash operation on the file header and data body containing the session key ciphertext to generate a context binding value;

[0073] S301. Obtain the pre-stored local encryption public key and encrypt the session key to obtain the session key ciphertext, as follows:

[0074] The pre-stored local encryption public key is specifically a receiver public key generated by the receiver based on the same elliptic curve system parameters as the sender, following steps S101 to S103. This receiver public key resides on the second addition cyclic group and is pre-stored at the sender using a pre-set security certificate or trusted key exchange protocol. Before encryption, the sender verifies the validity of the receiver public key using the following formula:

[0075] ,

[0076] in, The cofactor of the second additive cyclic group, the value of which depends on the preset extension field curve parameters; For the receiver's public key, symbol This represents elliptic curve scalar multiplication based on a quadratic extended field; if the calculation result If the distance is infinity, the receiving end's public key is deemed invalid and the system exits with an error message; otherwise, the verification is deemed successful.

[0077] Based on the verified public key of the receiving end, the session key is processed using an elliptic curve public key encryption algorithm to generate key ciphertext. Specifically, firstly, a random number generator that conforms to cryptographic security standards (such as HMAC-DRBG based on SM3) is used to generate an encrypted temporary random number that is only used for this encryption. Then, the encrypted temporary random number and the common base point are used to perform an elliptic curve scalar multiplication operation on the quadratic extended field, which is consistent with the logic of step S103. The result of the operation is the elliptic curve point component in the session key ciphertext structure.

[0078] Next, the elliptic curve scalar multiplication operation is performed on the encrypted temporary random number and the receiving end public key to obtain the encrypted shared point. This encrypted shared point is then serialized, following the big-endian encoding rule of "real part first, imaginary part second, high-order bits first." Specifically, the real part of the horizontal coordinate, the imaginary part of the horizontal coordinate, the real part of the vertical coordinate, and the imaginary part of the vertical coordinate of the encrypted shared point are extracted sequentially and concatenated into a binary bit stream. A key derivation function (such as the counter mode KDF based on SM3) is used as input to generate a key stream with the same bit length as the session key. Then, a bitwise XOR operation is performed on the key stream and the session key to obtain the ciphertext data component. Finally, the horizontal coordinate of the encrypted shared point, the session key, and the vertical coordinate of the encrypted shared point are concatenated sequentially, and the digest value of the session key ciphertext is calculated using the same cryptographic hash algorithm as in step S203.

[0079] Finally, following the ASN.1 standard encoding rules, a SEQUENCE structure containing three fields is constructed as the session key ciphertext. The elliptic curve point component, the key ciphertext digest value, and the ciphertext data component are respectively encapsulated into the three OCTETSTRING fields and serialized into a binary byte stream stored in memory to ensure the parsing consistency of the key ciphertext across different heterogeneous systems.

[0080] S302. Construct a file header containing the ciphertext of the session key, as follows:

[0081] A file header is constructed according to a preset data packet format standard to specify the transmission protocol and decryption parameters. The file header consists of a protocol version number, an encryption algorithm identifier, a data body length, and a session key ciphertext concatenated in a preset order, and all are encoded using network byte order (i.e., big-endian). No alignment bytes are padded between fields. The protocol version number occupies 2 bytes and is obtained by reading the locally stored protocol configuration register. For example, the configuration value 0x0100 is read to identify version V1.0, which is used to identify the data packet format version and compatibility. The encryption algorithm identifier occupies 2 bytes and is used to indicate the algorithm and mode used when encrypting the data body in step S2. For example, 0x0401 is written to identify the counter mode of the SM4 algorithm. The data body length occupies 4 bytes and is obtained by converting the binary stream length value of the data body into a 4-byte big-endian unsigned integer. The complete file header is obtained by concatenating the binary data in the order of "protocol version number || encryption algorithm identifier || data body length || key ciphertext".

[0082] S303. Concatenate the file header and the data body, and perform a hash operation on the concatenation result to obtain the context binding value, as follows:

[0083] The file header is used as the header data, and the data body is used as the payload data. The data is concatenated in binary format with the file header first and the data body last to form a complete data stream to be bound. Then, the same cryptographic hash algorithm as in step S203 is used to perform digest calculation on the complete data stream to be bound to obtain the context binding value.

[0084] This step provides a robust, tamper-proof, and tamper-proof raw data foundation for subsequent second-key signing by mathematically concatenating the file header and data body and calculating the context binding value for header-body binding. To verify the robustness of this method against micro-tampering attacks, this embodiment uses a general-purpose computing platform (configured as a Python 3.8 environment, calling the NumPy numerical computing library and the GmSSL cryptographic algorithm library) to conduct Monte Carlo simulation tests to verify the file header and data body concatenation binding mechanism constructed in this step. The test selected 1000 randomly generated secure data packets, performed random bit-flipping operations on their file headers, and statistically analyzed the difference in context binding values ​​before and after the flipping. The test results are as follows: Figure 2 As shown in the figure, the scatter distribution and mean line (red dashed line) indicate that any change in any bit in the file header will cause an avalanche change of about 128 bits (i.e., close to 50%) in the final context binding value. This makes it impossible for attackers to construct hash collisions by fine-tuning the file header, thus effectively ensuring the uniqueness and security of the header binding at the physical level.

[0085] S4. Concatenate the first verification public key, the second verification public key, and the context binding value, map them to a preset scalar field to obtain nonlinear constraint coefficients, and after weighted modulation of the binding value, generate a file header signature using the second private key, including:

[0086] In this embodiment, obtaining the nonlinear constraint coefficients in step S4 includes:

[0087] S401. Serialize the first verification public key and the second verification public key, then concatenate them with the context binding value and perform a digest operation, as follows:

[0088] Since both the first and second verification public keys are located on the second additive cyclic group, their x and y coordinates are elements on the quadratic extended field, i.e., complex numbers composed of two large integers from the base field. Therefore, when transforming the x and y coordinates, the real and imaginary integers in the x and y coordinates of the verification public keys are extracted respectively, and the four components are converted into big-endian binary integers of a fixed length determined by the base field parameters (e.g., 32 bytes per component and 64 bytes for a single coordinate under a 256-bit curve). If any component is too short, zero bits are automatically padded to its high bits. Subsequently, following the elliptic curve point serialization standard, a header byte 0x04 indicating the uncompressed format is added before the coordinate data to construct a standard uncompressed byte string in the format "0x04||real part of x coordinate||imaginary part of x coordinate||real part of y coordinate||imaginary part of y coordinate", to ensure the unique representation of the verification public key data at the binary level.

[0089] The first verification public key byte string, the second verification public key byte string, and the binary stream of the context binding value are concatenated end to end, and the same cryptographic hash algorithm as in step S203 is called to perform a digest operation on the concatenated bit string to obtain a data block digest value. The data block digest value is represented as a binary byte stream of fixed length (e.g., 256 bits).

[0090] S402. Using the obtained summary value, perform a modulo operation on the group order value of the preset elliptic curve to obtain the nonlinear constraint coefficients in the scalar domain, as follows:

[0091] The scalar field is defined by the prime group order of the selected elliptic curve, wherein the scalar field is defined by the prime group order. A finite set of integers modulo 1 Following the "byte-to-integer conversion primitive (OS2I)" defined in the public-key cryptography standard, and employing big-endian interpretation rules, the data block digest value in the form of the binary byte stream is converted into a mathematically significant positive integer; the positive integer is then used to perform a modulo operation (i.e., finding the remainder) on the group order value to ensure that the result is within the range specified by the public-key cryptography standard. Within the interval, the calculation result is the nonlinear constraint coefficient in the scalar domain;

[0092] Since the multiplication coefficients in the scalar field cannot be zero, the operation result needs to be checked for non-zero values: if the operation result is 0, the current data block digest value is concatenated with a preset fixed salt value (e.g., a 32-byte hexadecimal constant), the digest value is recalculated and modulo is taken to obtain a non-zero operation result; if the operation result is not zero, the operation result is directly used as the nonlinear constraint coefficient; since the operation process is fully homomorphic, when the receiving end reproduces the calculation and obtains a result of 0, it will automatically determine that the sending end has triggered salting and automatically recalculate using the same fixed salt value, thereby ensuring the strict synchronization and non-zero nature of the nonlinear constraint coefficients at both ends without adding an extra counter field to the data packet;

[0093] It should be noted that traditional multi-signature schemes typically rely on simple linear combinations of public keys, making them vulnerable to substitution attacks and difficult to defend against replay threats. This step constructs a nonlinear mapping mechanism based on dual public keys and content data to the elliptic curve scalar field, generating dynamic nonlinear constraint coefficients that contain both identity and content attributes. This ensures that the joint signature generated based on these coefficients is anchored to the dual public key credentials and the current context, thereby effectively eliminating the mathematical basis for key substitution attacks and improving the accuracy of identity authentication.

[0094] In this embodiment, obtaining the file header signature in step S4 includes:

[0095] The context binding value is mapped to the first additive cyclic group using a trial-and-error incremental hash mapping algorithm that is completely consistent with step S203. Specifically, the context binding value is used as input, and a series of operations with the same logic as step S203 are performed, including modulo reduction based on the prime field modulus of the elliptic curve, calculation of the square value of the theoretical ordinate, and quadratic residue determination based on the Euler criterion. If the determination is successful, the ordinate is calculated using a modular square root solution algorithm (such as the Tonelli-Shanks algorithm) to obtain the coordinate point of the valid context binding value. If the determination fails, the candidate value of the abscissa is incremented (e.g., the value is increased by 1) and retried until a valid coordinate point that satisfies the curve equation of the first additive cyclic group is found or the maximum number of incremental attempts is reached.

[0096] Using the nonlinear constraint coefficients as multipliers (scalars) and the context mapping points as multiplicands (base points), elliptic curve scalar multiplication is performed on the first addition loop group. The operation is logically isomorphic to step S103 but the domain is strictly limited to the base domain (prime domain). The coordinate points obtained from the operation are the weighted modulation points.

[0097] The file header signature is logically the same as the data body signature in step S203. Specifically, the second private key and the weighted modulation point are used to perform elliptic curve scalar multiplication, and the result is the file header signature. The weighted modulation point also plays the role of the common base point in step S103 in this operation. Similarly, the domain of operation for the file header signature in this step is the base field (prime field).

[0098] This step embeds context information into the weighted modulation points by using dynamic constraint coefficients generated based on nonlinear hash operations. This makes it difficult for attackers to reverse-engineer the context mapping points or forge signatures through the file header signature, thereby establishing a strong cryptographic dependency between the physical layer device identity and the logical layer data content.

[0099] S5. Encapsulate the file header, data body, data body signature, and file header signature to generate a secure data packet, including:

[0100] First, since both the data body signature and the file header signature are essentially geometric coordinate points on the first addition loop group, elliptic curve point addition operations, logically consistent with the point addition sub-step in step S103, can be directly performed on the data body signature and the file header signature. Furthermore, the algebraic calculations in this process are all based on the prime field modulus. Specifically, based on the chord-tangent rule, by calculating the slope of the line connecting the two coordinate points and the third intersection point with the elliptic curve, and taking the symmetrical point of the third intersection point about the X-axis, a unique sum point is derived on the first addition loop group, serving as a single global aggregate signature; such as Figure 3 As shown, Figure 3 The diagram illustrates the geometric principle of generating a single global aggregate signature. The green dashed line in the diagram represents the tangent-chord line, which passes through the point representing the data body signature and the point representing the file header signature, and extends to intersect the elliptic curve at the third intersection point (as shown by the green point in the diagram). The red vertical line represents the symmetric transformation path, that is, starting from the third intersection point, a vertical projection about the X-axis is made, and the red coordinate point obtained at the symmetrical position of the curve is the globally unique single global aggregate signature.

[0101] The x and y coordinates of the single global aggregate signature coordinate point are both large integers. Therefore, the x and y coordinates of the signature coordinate point are directly extracted, and the x and y coordinate components are converted into big-endian binary integers of fixed length (e.g., 32 bytes per coordinate component under a 256-bit curve). If the length of any component is insufficient, zero bits are automatically filled in its high bits. Then, a 0x04 header identifier is added before the coordinate data to construct a standard uncompressed byte string in the format "0x04||x-coordinate component||y-coordinate component", which is used as the signature data to be written into the final data packet.

[0102] The file header is placed at the beginning of the data packet as a fixed-length header; the data body is concatenated after the header in binary stream form as a variable-length payload; and the single global aggregate signature is placed at the end of the data packet as a fixed-length tail; thus completing the construction of the secure data packet.

[0103] This step merges the independent data body signature and file header signature into a single global signature point, requiring the receiving end to jointly verify both the file header and data body simultaneously. This mathematically locks in the header-body relationship and improves the overall reliability of the data packet structure.

[0104] To further verify the transmission advantages of this invention in constrained network environments (such as low-bandwidth scenarios in the power IoT), this embodiment constructed a simulation test environment (configured with an Intel Core i7 processor, 16GB of memory, and the algorithm implemented based on Python and the GmSSL library). The communication overhead of secure data packets using aggregated signatures was compared with that of data packets using traditional dual independent signatures. The test statistically analyzed the total number of bytes occupied by the protocol header and signature data under different concurrent packet volumes (0 to 5000 packets). The comparison results are as follows: Figure 4 As shown in the figure, the communication transmission bandwidth usage comparison trend between the present invention and the traditional method is illustrated. The red solid line in the figure represents the present invention's solution, and the gray dashed line represents the traditional dual overall signature scheme (such as SM2+SM2). It can be seen from the figure that because the present invention aggregates the two originally independent signatures (usually 64 bytes each, totaling 128 bytes) into a geometric coordinate point of about 65 bytes, the communication bandwidth usage of the signature part is reduced by about 50%. Moreover, as shown in the green filled area in the figure, as the amount of transmitted packets increases, the cumulative bandwidth resources saved by the present invention increase linearly, and the total bandwidth overhead is reduced by about 20% to 40%, effectively alleviating the network congestion pressure in high-concurrency scenarios.

[0105] Example 2: A secure data packet communication system includes a sender and a receiver; the sender is used to execute the secure data packet generation method that separates the header signature and the data body signature as described in Example 1, to generate a secure data packet and send it.

[0106] The receiving end is used to receive the security data packet and perform integrity verification on the security data packet based on a pre-established bilinear pair aggregation check equation, as follows:

[0107] Upon receiving a secure data packet, the receiving end first reads a fixed-length header of a preset fixed length (e.g., 200 bytes, depending on the curve parameters and padding mode) according to the known secure data packet body structure, and then parses the data body length field from it according to the file header structure. Subsequently, it continues to read a binary stream of the corresponding length based on the data body length field, which serves as the data body. After the data body is read, it continues to read a binary stream of a preset fixed length (e.g., 65 bytes), which serves as the single global aggregate signature at the end of the data packet.

[0108] Next, the single global aggregate signature is parsed and its validity verified. Since the aggregate signature generated by the sending end is essentially a geometric coordinate point on the first additive cyclic group, the receiving end directly parses the 65 bytes of data (including the 0x04 header identifier) ​​into an uncompressed elliptic curve point and extracts the large integers of the horizontal and vertical coordinates. Subsequently, the large integers of the horizontal and vertical coordinates are substituted into the curve equation of the first additive cyclic group for verification. If the equation does not hold, it means that the coordinate point of the aggregate signature is not on a valid elliptic curve, indicating that the data packet has experienced bit errors or has been maliciously tampered with during transmission. The receiving end immediately terminates the process and discards the data packet. If the equation holds, the coordinate point of the aggregate signature is used as the point for reconstructing the aggregate signature, and subsequent cryptographic verification steps are performed.

[0109] Subsequently, the receiving end performs a data reconstruction operation mirrored that of the sending end. Specifically, it calls the same cryptographic hash algorithm (such as SM3) as the sending end to perform a digest operation on the parsed data body, and uses a hash mapping algorithm consistent with step S203 in Embodiment 1 to map the data body digest value onto the first additive cyclic group to obtain the data body mapping point. At the same time, based on the parsed file header and data body, the receiving end reconstructs the context binding value using the same method as step S303 in Embodiment 1, and combines the locally stored first verification public key and second verification public key to reconstruct the nonlinear constraint coefficients using the method of step S4 in Embodiment 1. The reconstructed context binding value is mapped to the reconstructed context mapping point, and scalar multiplication is performed using the reconstructed nonlinear constraint coefficients to obtain the reconstructed weighted modulation point.

[0110] Subsequently, the receiving end uses a pre-defined bilinear pairing algorithm (such as the optimal Ate pairing algorithm) to verify the mathematical relationship, where the bilinear pairing aggregation verification equation is as follows:

[0111]

[0112] in, This represents the bilinear pairing operation. To reconstruct the aggregate signature point, is the common base point of the elliptic curve. For data volume mapping points, To reconstruct the weighted modulation points, , These are the first verification public key and the second verification public key, respectively. This means that the bilinear pairing value between the data volume mapping point and the first verification public key, and the bilinear pairing value between the reconstructed weighted modulation point and the second verification public key are multiplied on the twelveth extension field.

[0113] If the equation of the bilinear pair aggregation verification is true, it indicates that the single global aggregation signature is valid and that neither the data body nor the file header has been tampered with. It also verifies the correctness of the context relationship of the secure data packet. The receiving end determines that the data packet verification is successful and allows the data to proceed with subsequent decryption. If the equation is false, it indicates that the data packet has problems such as content tampering, header-body separation attack, or public key substitution attack. The receiving end determines that the verification has failed and performs packet loss or alarm processing.

[0114] In this embodiment, the receiving end utilizes the property of bilinear pairing to directly verify the topological mapping relationship between the aggregate signature, the dual public key, and the dual message digest. This simplifies the integrity verification process, reduces the computational load and verification latency of the receiving end in high-concurrency communication scenarios, and improves verification efficiency.

[0115] The above formulas are all dimensionless calculations. The formulas are derived from software simulations using a large amount of collected data, and are the closest to the real situation. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

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

[0117] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0118] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0119] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0120] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for generating secure data packets that separates header signature from data body signature, characterized in that, Includes the following steps: Randomly generate a first private key and a second private key, and perform a group transformation to obtain a first verification public key and a second verification public key; The directory structure information and file content data of the original file are encrypted using a preset session key. The structure stream and the encrypted file stream are then concatenated and combined to generate a data body. The data body signature is then obtained by signing the data body using the first private key. Perform a concatenated hash operation on the file header and data body containing the session key ciphertext to generate a context binding value; The digest value is calculated by concatenating the first verification public key, the second verification public key, and the context binding value. Based on the preset elliptic curve parameters, the digest value is mapped to a nonlinear constraint coefficient in a preset scalar domain. The coordinates on the elliptic curve are calculated from the context binding value, the coordinates are weighted using the constraint coefficients, and the weighted result is signed using the second private key to obtain the file header signature; Encapsulate the file header, data body, data body signature, and file header signature to generate a secure data packet.

2. The secure data packet generation method that separates the header signature from the data body signature according to claim 1, characterized in that, The preset elliptic curve parameters include at least the group order value and prime field modulus of the preset elliptic curve, and the mapping of the summary value to nonlinear constraint coefficients in a preset scalar field includes: The nonlinear constraint coefficients in the scalar domain are obtained by performing a modulo operation on the group order value of the preset elliptic curve using the summary value, wherein the scalar domain is a set of integers modulo the group order value.

3. The secure data packet generation method that separates the header signature from the data body signature according to claim 2, characterized in that, Obtaining the file header signature includes: Based on the prime field modulus, the context binding value is reduced by modulus and the coordinate point on the elliptic curve is obtained by solving the curve equation of the preset elliptic curve. The coordinate point is then multiplied by scalar using the nonlinear constraint coefficient as a weighting factor to obtain the weighted modulation point. The weighted modulation point is signed using the second private key to obtain the file header signature.

4. The secure data packet generation method that separates the header signature from the data body signature according to claim 1, characterized in that, The encapsulated file header, data body, data body signature, and file header signature include: Based on the additive homomorphism property of elliptic curves, a point addition operation is performed on the data body signature and the file header signature to generate a single global aggregate signature; According to the preset structure, the file header, data body, and single global aggregate signature are encapsulated to obtain a secure data packet.

5. The secure data packet generation method that separates the header signature from the data body signature according to claim 1, characterized in that, Obtaining the first verification public key and the second verification public key includes: Within an integer field defined by a preset elliptic curve group order value, a first private key for signing the data body and a second private key for signing the file header and context binding relationship are randomly generated. Using the base point parameters of a preset elliptic curve, scalar multiplication is performed on the first private key and the second private key respectively to obtain the corresponding first verification public key and second verification public key that characterize the mathematical features of the private key.

6. The secure data packet generation method that separates the header signature from the data body signature according to claim 1, characterized in that, The session key ciphertext is obtained by encrypting a preset session key with a pre-stored local encryption public key, and includes a key ciphertext digest value and a ciphertext data component obtained by XORing the session key.

7. A secure data packet communication system, characterized in that, Includes the sending end and the receiving end; The sending end is configured to execute the secure data packet generation method for separating the file header signature and the data body signature as described in any one of claims 1 to 6, generate a secure data packet and send it; The receiving end is used to receive the security data packet and perform integrity verification on the security data packet based on a pre-established bilinear pair aggregation check equation.

8. The secure data packet communication system according to claim 7, characterized in that, The bilinear pair aggregation verification equation is as follows: in, This represents the bilinear pairing operation. For a single global aggregate signature in a secure data packet. To preset the base point parameters of the elliptic curve, The weighted modulation points are reconstructed at the receiving end. , These are the first verification public key and the second verification public key, respectively. The data body mapping point is specifically the coordinate point obtained by the receiving end through hashing the data body and mapping the result to a preset elliptic curve.

Images