A method for protecting integrity of satellite-ground service based on transform-constant code

Abstract

The application relates to the fields of satellite communication and network security, and discloses a satellite-ground service integrity protection method based on transformation conservation codes, which comprises the following steps: obtaining a protocol transformation sequence of a satellite-ground service stream, generating a window check factor based on a satellite visible time window; encoding protocol fields and payload block features into finite field semantic vectors, configuring sparse transformation matrices and permitted change vectors at all levels, and reversely generating coefficient vectors at all levels; generating transformation conservation codes according to actual output semantic vectors by an isolation check module at each level, checking adjacent conservation code relationships, window identifiers, operation identifiers and matrix versions step by step, determining abnormal positions and blocking service streams. The application can check the multi-level protocol transformation integrity in the case of allowing permitted changes of protocol fields, and can reduce the construction and comparison of complete expected messages.

Description

Technical Field

[0001] This invention relates to the fields of satellite communication and network security technology, specifically to a method for protecting the integrity of satellite-to-ground services based on transformation conservation codes. This method is applicable to data integrity verification, integrity anomaly location, and service flow security handling when satellite-to-ground service flows undergo multi-level protocol transformations in integrated space-ground networks. Background Technology

[0002] With the development of low-Earth orbit satellite constellations, satellite internet, and integrated space-ground information networks, there is a continuous need to transmit telemetry data, service payloads, control information, and network management information between satellite nodes, gateway stations, ground data centers, and user networks. Due to differences in communication protocols, equipment interfaces, and network architectures, satellite-to-ground service flows typically require multiple levels of protocol transformation during transmission, including protocol parsing, field mapping, address translation, message encapsulation, message decapsulation, and payload reassembly, to achieve interconnection between space-based and terrestrial networks.

[0003] After protocol transformation, the protocol header, field positions, message length, and payload fragmentation format of satellite-to-ground traffic may change. For example, the protocol type field, source address field, destination address field, sequence field, and time-to-live field may be rewritten according to the protocol transformation rules, and the traffic payload may also change its position in the message due to fragmentation, reassembly, or encapsulation operations. Therefore, although the messages before and after protocol transformation are different in binary form, the business semantics they carry should remain consistent. If the digest value or signature value of the complete messages before and after protocol transformation is directly compared, legitimate field rewriting and message structure adjustments will also cause inconsistent comparison results, making it difficult to distinguish between permitted protocol transformations and unpermitted data changes.

[0004] Existing integrity verification methods typically perform digest calculations on data whose content remains unchanged, or generate expected output messages based on preset protocol conversion rules, and then compare the actual output message with the expected output message field by field. When satellite-to-ground service flows continuously through multiple protocol conversion modules, generating and saving complete expected output messages at each level will correspondingly increase the computing and storage resources consumed by expected message construction, message field comparison, and intermediate data storage. Furthermore, when an anomaly occurs in the protocol conversion result at a certain level, it is difficult to determine the earliest protocol conversion location where the abnormal data appeared based solely on the integrity verification results at the service flow's inlet and outlet.

[0005] Furthermore, the communication relationship between satellites and gateway stations is affected by satellite orbits, gateway station coverage areas, and minimum communication angles, exhibiting characteristics of limited visibility time and periodic link switching. The satellite nodes, gateway stations, and protocol transformation paths involved in service transmission may change within different visible time windows. If there is a lack of correlation between integrity verification information and the actual visible time window, verification information generated within adjacent visible time windows may be difficult to distinguish effectively, thus hindering the identification of service data or verification records reused across windows. Therefore, it is necessary to continuously verify the results of multi-level protocol transformations while allowing protocol fields to change according to established rules, and to determine the location of the first abnormal protocol transformation while reducing the transmission and comparison operations of complete expected messages.

[0006] In the prior art, patent application CN110290105A, entitled "A Verification Platform and Method for Heterogeneous Protocol Conversion," discloses a verification platform including a configuration management module, a packet-driven module, a protocol conversion module, a reference model, and an output monitoring module. The reference model performs heterogeneous protocol conversion on the stimulus sequence to obtain the expected output packet. The output monitoring module samples the output data of the protocol conversion module to obtain the actual output packet and compares the actual output packet with the expected output packet by field comparison to obtain a comparison result characterizing whether the heterogeneous protocol conversion was successful. This application reflects a technical implementation method in the prior art that verifies the protocol conversion result by constructing an expected output packet and comparing its field with the actual output packet after protocol conversion. Summary of the Invention

[0007] The purpose of this invention is to provide a satellite-to-ground service integrity protection method based on transformation conservation codes, which continuously verifies the integrity of the transformation results at each level when the satellite-to-ground service flow undergoes multiple levels of protocol transformation and the message structure and some protocol fields undergo permission changes, determines the first protocol transformation module or verification boundary that has an integrity abnormality, and reduces the resource overhead generated by constructing, transmitting and comparing complete expected output messages.

[0008] To achieve the above objectives, this invention provides a satellite-to-ground service integrity protection method based on transform-conserving codes, comprising:

[0009] Obtain the protocol transformation sequence and operation identifiers at each level of the satellite-to-ground service flow;

[0010] The current visible time window is determined based on the satellite ephemeris and the coverage area of ​​the gateway station, and a window verification factor is generated based on the window identifier, random number and service flow identifier of the current visible time window;

[0011] According to the preset semantic encoding rules, the feature values ​​and block identifiers of the service retention field, permission rewrite field, and fixed-granularity payload blocks determined by the protocol field mapping rules of each level of protocol transformation are encoded into semantic vectors over the finite field GF(q).

[0012] Configure sparse transformation matrices for each level of protocol transformation. Permitted change vector And matrix version, so that the expected output semantic vector of the i-th level protocol transformation is changed from the semantic vector before transformation through Linear transformation and superposition get;

[0013] Generate the final-level coefficient vector based on the window check factor. From the last level to the first level, the coefficient vector of the next level is multiplied by the transpose of the corresponding sparse transformation matrix to obtain the coefficient vector of the previous level.

[0014] The initial conserved code is obtained by calculating the inner product of the initial coefficient vector and the initial semantic vector by the entry verification module.

[0015] The verification module, located at the output end of each level of protocol transformation module and isolated from the corresponding protocol transformation module, extracts the actual output semantic vector from the actual output data according to the preset semantic coding rules, calculates the inner product of the corresponding level coefficient vector and the actual output semantic vector, and obtains the corresponding level transformation conservation code.

[0016] Determine step by step whether the difference between the current level transform conservation code and the previous level transform conservation code is equal to the inner product of the current level coefficient vector and the permitted change vector, and verify the window identifier, operation identifier and matrix version;

[0017] The first protocol transformation module that fails the inner product check is identified as an abnormal module, the first check location that fails the identifier check is identified as an abnormal boundary, and the business flow corresponding to the abnormal module or the abnormal boundary is blocked.

[0018] Where n is the protocol transformation level, i is the protocol transformation level from 1 to n, and q is a prime number.

[0019] Preferably, the preset semantic encoding rules include:

[0020] Establish semantic coordinate tables for each level of protocol transformation before and after transformation, and establish mapping relationships between semantic coordinates corresponding to protocol fields with the same business meaning;

[0021] The payload is divided into blocks according to the byte offset of the satellite-to-ground service flow rather than the protocol message boundary. Each payload block is defined as a check data unit. Check unit numbers are assigned to each check data unit, and the characteristic values ​​of each payload block are calculated.

[0022] The protocol field values, payload block feature values, and block identifiers are mapped to domain elements in GF(q) and written to the corresponding semantic coordinates;

[0023] Fill the semantic coordinates of the optional protocol fields that are not carried by the current verification data unit in the semantic coordinate table with zeros to obtain the semantic vectors before and after the transformation of each level of protocol.

[0024] Preferably, sparse transformation matrices are configured for each level of protocol transformation. ,include:

[0025] Use the semantic coordinates after the i-th level protocol transformation as the matrix rows, and use the semantic coordinates before the i-th level protocol transformation as the matrix columns;

[0026] For semantic coordinates before and after that have a relationship of inheritance of field values ​​or load block feature values, the corresponding matrix element is configured to 1;

[0027] For semantic coordinates before and after that have no inheritance relationship, the corresponding matrix elements are set to 0, making the sparse transformation matrix... It represents the field retention, copying, reordering, and deletion relationships in the corresponding protocol transformation.

[0028] Preferably, a license change vector is configured for each level of protocol transformation. And matrix versions, including:

[0029] Obtain the address translation parameters, encapsulation identifier, protocol type identifier, sequence adjustment parameters, and time-to-live adjustment parameters used for the i-th level protocol transformation;

[0030] by This represents the semantic vector before the i-th level protocol transformation obtained according to the preset semantic encoding rules, using... This represents the expected output semantic vector determined at the semantic coordinate level according to the protocol field mapping rules and permission change parameters, and the permission change vector is calculated on GF(q) according to the following formula. :

[0031] ;

[0032] right , The corresponding operation identifier is encoded and calculated to obtain the matrix version, and the matrix version is bound to the currently visible time window.

[0033] Preferably, the process involves generating a final-level coefficient vector based on the window check factor, and generating coefficient vectors for each level from the final level to the first level, including:

[0034] Using the root verification key as the key material, and using the window identifier, random number, and service flow identifier as derived inputs, key derivation operations are performed to obtain the window verification factor.

[0035] Using the window verification factor as the key, and the level identifier of the final-level protocol transformation and the component numbers of the final-level semantic vector as input, pseudo-random operations are performed.

[0036] The results of each operation are mapped to GF(q), and the components with zero values ​​in the mapping results are replaced with preset non-zero values ​​to obtain the final-order coefficient vector. ;

[0037] The coefficient vectors for each level are generated sequentially from the last level to the first level according to the following formula:

[0038] · ;

[0039] The superscript T indicates matrix transpose.

[0040] Preferably, the verification module, isolated from the protocol transformation module, extracts the actual output semantic vector from the actual output data, including:

[0041] The system receives the corresponding level coefficient vector, permission change vector, window verification factor, window identifier, and protocol transformation sequence containing operation identifiers and matrix versions at each level through an independent verification channel, and stores the received information in an isolated storage area that the protocol transformation module cannot write to.

[0042] The actual output data is obtained through a hardware mirroring channel set between the output interface of the protocol conversion module and the network transmission interface;

[0043] According to the preset semantic encoding rules, the actual output data is converted into an actual output semantic vector with the same dimension as the corresponding level coefficient vector.

[0044] Preferably, the verification window identifier, operation identifier, and matrix version include:

[0045] The entry verification module or the previous level verification module encapsulates the business flow identifier, verification unit number, window identifier, operation identifier and matrix version of the protocol transformation to be executed in the current level, and the transformation conservation code of the previous level into a bypass verification record, and generates a record authentication value based on the window verification factor and the bypass verification record; when the current level is the first level, the transformation conservation code of the previous level is the initial conservation code;

[0046] The bypass verification record and the record authentication value are sent to the current-level verification module through an independent verification channel;

[0047] The current-level verification module associates the bypass verification record with the corresponding verification data unit based on the service flow identifier and verification unit sequence number. First, it matches the window identifier with the local currently visible time window. If the window identifier matches and the reception time of the verification data unit is within the current visible time window, it verifies the record authentication value. After successful verification, it matches the operation identifier and matrix version with the locally configured current-level operation identifier and current-level matrix version, respectively. If the record authentication value verification fails, the bypass verification record is rejected and the corresponding verification data unit is blocked.

[0048] After the current level protocol transformation is completed, the current level transformation conservation code is generated, and the inner product check is performed using the previous level transformation conservation code in the bypass check record;

[0049] When the authentication value verification is successful and both the inner product verification and the identifier verification are successful, the business data output by the current level protocol transformation module is allowed. When there is a next-level protocol transformation, the business flow identifier, verification unit number, window identifier, next-level operation identifier, matrix version, and current-level transformation conservation code are encapsulated into the next bypass verification record, the corresponding record authentication value is generated, and sent to the next-level verification module. When there is no next-level protocol transformation, the business data is sent to the target business node.

[0050] Preferably, the current visible time window is determined based on the satellite ephemeris and the gateway station coverage area, including:

[0051] The times when the satellite enters and leaves the coverage area of ​​the gateway station are determined based on the satellite ephemeris, the location of the gateway station, and the minimum communication angle.

[0052] The sum of the maximum satellite-to-ground transmission delay and the maximum relative clock error between the verification nodes is determined as the window protection duration.

[0053] The entry time is delayed by the window protection duration, and the exit time is advanced by the window protection duration to obtain the currently visible time window;

[0054] Transform conservation codes and their corresponding service data that do not match the window identifier will be invalidated, and transform conservation codes and their corresponding service data received outside the current visible time window will also be invalidated.

[0055] Preferably, the determination of the abnormal module or abnormal boundary includes:

[0056] If the window identifier, operation identifier, and matrix version have all been verified, but the difference between the current level transformation conservation code and the previous level transformation conservation code is not equal to the inner product of the current level coefficient vector and the permitted change vector, the current level protocol transformation module will be identified as a semantic change abnormal module.

[0057] When the operation identifiers are discontinuous or the order of the operation identifiers is inconsistent with the protocol transformation sequence, the verification position of the first bypass verification record of the received mismatched operation identifier is determined as the transformation sequence abnormal boundary.

[0058] When the matrix version is inconsistent with the locally configured matrix version, the verification position of the first bypass verification record of the mismatched matrix version is determined as the abnormal boundary of the transformation rule.

[0059] When the window identifier does not match the current visible time window, the verification position of the bypass verification record with the mismatched window identifier is determined as the cross-window replay anomaly boundary.

[0060] Preferably, blocking the business flow corresponding to the abnormal module or abnormal boundary includes:

[0061] The verification module at the output end of the anomaly module or the downstream side of the anomaly boundary sets the corresponding output queue to a blocking state and stops forwarding service data that has not yet passed the verification.

[0062] When the anomaly type is semantic change anomaly, transformation order anomaly, or transformation rule anomaly, the nearest upstream verification node that has passed both inner product verification and identifier verification is determined as the recovery checkpoint. Among them, when the first-level protocol transformation module or its input boundary is determined as the anomaly location, the entry verification module is determined as the recovery checkpoint.

[0063] Based on the operation identifier corresponding to the abnormal position in the protocol transformation sequence and the locally configured matrix version, a backup protocol transformation module capable of executing the remaining protocol transformation sequence from the abnormal position is selected; the recovery checkpoint generates a first-level recovery bypass verification record and a record authentication value based on the operation identifier corresponding to the abnormal position and the locally configured matrix version, according to the saved service flow identifier, verification unit number, window identifier, and previous-level transformation conservation code, and sends the saved service data, the first-level recovery bypass verification record, the record authentication value, and the remaining protocol transformation sequence to the backup protocol transformation module;

[0064] The backup protocol transformation module executes each level of protocol transformation sequentially according to the remaining protocol transformation sequence. After each level of protocol transformation is completed, the verification module, which is isolated from the protocol transformation of that level, generates a transformation conservation code based on the actual output semantic vector of that level, verifies the record authentication value of the corresponding bypass verification record, performs inner product verification using the previous level's transformation conservation code in the corresponding bypass verification record, and verifies the window identifier, operation identifier, and matrix version. When the current level is not the last level of the remaining protocol transformation sequence and all verifications of that level pass, the next bypass verification record and its corresponding record authentication value are generated, and the next level of protocol transformation continues to be executed.

[0065] When the record authentication value verification, inner product verification and identifier verification at each level in the remaining protocol transformation sequence all pass, the blocking state is lifted, and the business data that completes the remaining protocol transformation sequence is sent to the target business node.

[0066] When any level of record authentication value verification, inner product verification, or identifier verification fails, the blocking state is maintained, the corresponding business data generated by the backup protocol transformation module is discarded, and a new backup protocol transformation module is selected.

[0067] When the exception type is cross-window replay, the corresponding business flow is paused, business data and bypass verification records with mismatched window identifiers are discarded, the corresponding protocol transformation module remains unchanged, the random number, window verification factor and coefficient vectors at all levels are updated, and the corresponding business flow is restored after the updated verification parameters are synchronized to the verification modules at all levels.

[0068] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0069] (1) This invention uses a sparse transformation matrix to characterize the inheritance relationship of service retention fields and payload blocks during the protocol transformation process, and uses a permission change vector to characterize permission field changes such as address translation, protocol encapsulation and sequence adjustment, so that integrity verification can adapt to the situation where the message structure and some field values ​​change before and after the protocol transformation.

[0070] (2) The present invention generates a fixed-length transformation conservation code by using coefficient vectors at each level and actual output semantic vectors. It does not require transmitting the complete expected output message between protocol transformation nodes at each level, which can reduce the processing resources occupied by expected message construction, message field comparison and intermediate result storage.

[0071] (3) The present invention performs inner product verification and identifier verification step by step according to the protocol transformation sequence. It can determine the abnormal protocol transformation module based on the inner product verification result and determine the abnormal protocol transformation boundary based on the identifier verification result, thereby narrowing the location range of abnormal data.

[0072] (4) The present invention associates the window verification factor with the satellite visible time window, random number and service flow identifier, so that different visible time windows use different verification parameters, which makes it easier to identify service data that do not match window identifiers and are replayed across windows.

[0073] (5) The present invention blocks the service data that fails the verification at the output end of the abnormal module or the downstream side of the abnormal boundary, and uses the verification node that passed the verification most recently as the recovery checkpoint to transfer the subsequent protocol transformation to the backup protocol transformation module; for cross-window replay abnormalities, the mismatched service data and bypass verification records are discarded and the verification parameters are updated, thereby preventing the abnormal service data from continuing to be transmitted. Attached Figure Description

[0074] Figure 1 This is a schematic diagram of the overall process of the satellite-to-ground service integrity protection method based on transformation conservation codes in an embodiment of the present invention;

[0075] Figure 2 This is a schematic diagram illustrating the process of semantic vector encoding, sparse transformation matrix and permitted change vector configuration, and generation of coefficient vectors at each level in an embodiment of the present invention.

[0076] Figure 3 This is a schematic diagram illustrating the connection relationship between the protocol conversion module, the isolated verification module, and the independent verification channel in an embodiment of the present invention.

[0077] Figure 4 This is a schematic diagram illustrating the determination of the current visible time window based on satellite ephemeris and gateway station coverage area in an embodiment of the present invention;

[0078] Figure 5 This is a schematic diagram illustrating the process of determining the abnormal module and abnormal boundary and handling the security of the business flow in an embodiment of the present invention. Detailed Implementation

[0079] The following is combined Figures 1 to 5 The present invention will be further described below. This embodiment provides a complete technical solution for satellite service data entering the gateway station, undergoing multi-level protocol transformation, completing integrity verification, and performing blocking and recovery in case of anomalies. The space packet protocol, Internet protocol, tunneling encapsulation protocol, key derivation algorithm, and message authentication algorithm used in the implementation process can all be implemented using existing technologies in the field.

[0080] Example 1

[0081] This embodiment is applied to an integrated space-ground network consisting of satellite nodes, gateway stations, ground edge nodes, and ground data centers. Satellite nodes transmit service data in space packet format. The gateway station converts the space packets into UDP / IPv6 packets that the ground network can process. Ground edge nodes perform address mapping and VXLAN encapsulation on the UDP / IPv6 packets. The ground data center ingress node performs VXLAN decapsulation and distributes the service data to the target service system.

[0082] This results in a three-level protocol transformation sequence:

[0083] The first-level protocol transformation is used to convert space packets into UDP / IPv6 messages, and the operation is identified as OP01;

[0084] The second-level protocol transformation is used to perform IPv6 address mapping, hop count limit field adjustment and VXLAN encapsulation, and the operation is identified as OP02;

[0085] The third-level protocol transformation is used to perform VXLAN decapsulation and UDP service distribution, and the operation is identified as OP03.

[0086] Each protocol transformation stage is executed by a separate protocol transformation module. Each protocol transformation module has a verification module at its output, and an entry verification module is located at the gateway station entry point. The verification module is implemented using a data processing unit independent of the protocol transformation software; in this embodiment, a smart network interface card (NIC) with an isolated storage area is used as the verification module. The protocol transformation module cannot read or modify the window verification factor, permission change vector, coefficient vectors at each level, protocol transformation sequence, operation identifier, or matrix version in the isolated storage area.

[0087] I. Determining the Currently Visible Time Window

[0088] Combination Figure 1 and Figure 4 The verification control node in the gateway station acquires the satellite ephemeris, the gateway station's latitude and longitude, and the minimum communication angle. In this embodiment, the minimum communication angle is set to 10 degrees. The elevation angle of the satellite relative to the gateway station is calculated based on the satellite's orbital position and the gateway station's position. The moment when the satellite's elevation angle rises to 10 degrees is determined as the moment it enters the gateway station's coverage area, and the moment when the satellite's elevation angle falls to 10 degrees is determined as the moment it leaves the gateway station's coverage area.

[0089] During a satellite transit, the calculated entry time into the coverage area is 10:00:00, and the departure time is 10:08:00. The maximum satellite-to-ground transmission delay is 80 milliseconds, and the maximum relative clock error between each verification node is 20 milliseconds. Therefore, 100 milliseconds is determined as the window protection duration. Delaying the entry time by 100 milliseconds and advancing the departure time by 100 milliseconds, the current visible time window is from 10:00:00.100 to 10:07:59.900 seconds.

[0090] The verification control node concatenates the satellite identifier, gateway identifier, window start time, and window end time in a predetermined order, calculates the SHA-256 digest, and extracts the first 128 bits of the digest as the window identifier. Simultaneously, the verification control node uses a cryptographically secure random number generator to generate a 256-bit random number.

[0091] After receiving the first space packet, the gateway station generates a service flow identifier based on the satellite identifier, the application process identifier in the space packet, the service destination node, and the receive session sequence number. The service flow identifier remains unchanged within the current visible time window and is regenerated when entering the next visible time window.

[0092] The verification control node uses a 256-bit root verification key pre-stored in the hardware security module as the key material, a random number as the salt value, and the window identifier, service flow identifier, and protocol transformation sequence identifier as derived information. It then uses the HKDF-SHA-256 key derivation algorithm to generate a 256-bit window verification factor. This window verification factor is sent to each verification module only through an independent verification channel, and not to the protocol transformation module.

[0093] II. Generation of Semantic Vectors

[0094] Combination Figure 2 Each verification control node establishes a semantic coordinate table for the protocol data before and after each protocol transformation. Each semantic coordinate table records at least the semantic coordinate number, protocol field name, field length, encoding method, field source, corresponding coordinates after transformation, and field change type.

[0095] This embodiment divides the protocol fields into service retention fields and license rewrite fields.

[0096] The service retention fields include the service flow identifier, application process identifier, service type identifier, payload block identifier, and payload block characteristic value. After protocol transformation, the message position or field name of the service retention fields may change, but their service meaning remains unchanged.

[0097] The permission rewrite fields include source address, destination address, protocol type, port number, sequence number, hop count limit, and tunnel identifier. The permission rewrite fields are generated according to the corresponding protocol transformation rules, resulting in the addition, deletion, or adjustment of specific fields.

[0098] For the service payload, the ingress verification module does not divide the payload according to the boundaries of spatial packets or IP packets. Instead, it divides the payload into 1024-byte blocks based on the continuous byte offset of the service flow, and defines each payload block as a verification data unit. The ingress verification module assigns a verification unit sequence number to each verification data unit according to the order of the payload blocks in the service flow. When the verification data unit is divided into multiple protocol packets during protocol transformation, each level of the verification module aggregates the payload data from multiple protocol packets based on the service flow identifier, verification unit sequence number, and payload byte offset. After the verification data unit is complete, the actual output semantic vector is generated. If the last payload block is less than 1024 bytes, the actual length of the payload block is added when calculating the feature value to avoid generating the same input after padding payloads of different lengths with zeros.

[0099] The entry verification module concatenates the payload block length, payload block identifier, and payload block content. It then uses the SHA-256 algorithm to calculate the payload block digest, converts the digest to an integer in big-endian byte order, and takes the modulo q to obtain the payload block feature value. In this embodiment, a 256-bit prime number greater than the encoded values ​​of each protocol field is selected as q during actual operation, ensuring that a finite field element is stored using 32 bytes.

[0100] For protocol fields with encoded values ​​less than q, the encoded values ​​are directly mapped to field elements in GF(q). For protocol fields with encoded values ​​not less than q, the field is split into multiple field components with a fixed word length, and each field component is written to its corresponding semantic coordinates. For fields not defined by the target protocol, semantic coordinates are not set in the semantic coordinate table corresponding to the target protocol; for optional fields that are defined by the target protocol but not carried by the current verification data unit, the corresponding semantic coordinates are filled with zeros.

[0101] Through the above processing, although space packets, UDP / IPv6 messages, and VXLAN encapsulated messages have different message structures, they can still form corresponding semantic vectors according to their business meanings.

[0102] III. Configuration of Sparse Transformation Matrix and Permissible Transformation Vector

[0103] The verification control node establishes a sparse transformation matrix for each level of protocol transformation according to the protocol field mapping rules. .

[0104] The columns of the sparse transformation matrix Aᵢ correspond to the semantic coordinates before the transformation of the i-th level protocol, and the rows correspond to the semantic coordinates after the transformation of the i-th level protocol. For semantic coordinates that have a field value inheritance relationship before and after the transformation, the corresponding matrix element is configured to 1; for semantic coordinates that do not have a field value inheritance relationship, the corresponding matrix element is configured to 0.

[0105] When the same business field is copied to multiple protocol fields after protocol transformation, the matrix element corresponding to the same input semantic coordinate is configured to 1 in the matrix rows corresponding to multiple output semantic coordinates. When only the position of the field is adjusted, the semantic coordinates are reordered by changing the row where the matrix element is located. When a field is deleted after protocol transformation, the semantic coordinate table after transformation will no longer set the corresponding output coordinates for that field.

[0106] The sparse transformation matrix is ​​stored in a compressed sparse row format, which includes an array of row pointers, an array of column indices, and an array of non-zero elements, thus eliminating the need to store matrix elements with a value of 0.

[0107] For fields added or rewritten according to rules during protocol transformation, the verification control node directly determines the expected change of each licensed rewritten field in semantic coordinates based on address translation parameters, encapsulation parameters, protocol type parameters, and field adjustment parameters, and generates a licensed change vector accordingly. No need to construct the complete expected output message. To illustrate the calculation relationship of the permission change vector, using... Represents the semantic vector before the i-th level protocol transformation, in The permissive change vector is calculated as follows, representing the expected output semantic vector determined at the semantic coordinate level according to the protocol field mapping rules:

[0108] .

[0109] For example, the first-level protocol transformation maps the application procedure identifier of the space packet to the UDP destination port and adds an IPv6 next header field. In this embodiment, the UDP destination port is set to be equal to the sum of the application procedure identifier and the preset port base value. The inheritance relationship of the application procedure identifier is represented by a sparse transformation matrix, and the preset port base value and the newly added IPv6 next header field are represented by a permission change vector.

[0110] The second-level protocol transformation replaces the original destination address with the terrestrial data center address, decrements the hop count limit field by 1, and adds a VXLAN network identifier. The changes to the destination address, hop count limit field, and VXLAN network identifier are all written into the corresponding license change vector for the second-level protocol transformation.

[0111] The verification control node serializes the window identifier, operation identifier, number of matrix rows, number of matrix columns, compressed sparse row data, permission change vector, and rule effective time in a fixed order, calculates the SHA-256 digest, and extracts the first 128 bits of the digest as the matrix version. The matrix version is regenerated when the protocol field mapping rules or permission change parameters change.

[0112] IV. Generation of coefficient vectors at each level

[0113] The verification control node uses the window verification factor as the HMAC-SHA-256 key, and takes the level identifier of the final-level protocol transformation, the service flow identifier, and the component sequence number of the final-level semantic vector as inputs in sequence to calculate the pseudo-random value corresponding to each semantic vector component.

[0114] After converting each pseudo-random value to an integer and taking the modulo of q, the final-order coefficient vector r is obtained. n The corresponding component in the semantic vector. If the mapping result is 0, the component is replaced with 1 to avoid the corresponding component in the semantic vector not participating in the transformation conservation code calculation.

[0115] Obtain the final coefficient vector r nThen, the verification control node reverses the process from the final-level protocol transformation to the first-level protocol transformation, generating coefficient vectors for each level according to the following formula:

[0116] · .

[0117] Due to the sparse transformation matrix The semantic coordinate inheritance relationship before and after the transformation has been recorded. Therefore, the coefficient vector generated by the transpose matrix can ensure that the same business semantics maintains the corresponding projection coefficients in different protocol structures.

[0118] The verification control node sends the corresponding level coefficient vector, permission change vector, window verification factor, and window identifier, as well as the protocol transformation sequence containing operation identifiers and matrix versions at each level, to each verification module through an independent verification channel. Each verification module stores the received information in an isolated storage area that the protocol transformation module cannot write to. The independent verification channel uses a different virtual routing forwarding domain than the business data channel and transmits verification parameters through a two-way authenticated encrypted connection.

[0119] V. Generation and Verification of Transformation Conservation Codes

[0120] After receiving the satellite-to-ground service flow, the ingress verification module generates an initial semantic vector according to the semantic coordinate table, calculates the inner product of the initial coefficient vector and the initial semantic vector, and takes the result modulo q to obtain the initial conserved code. The ingress verification module reads the first-level operation identifier OP01 and the first-level matrix version from the protocol transformation sequence, encapsulates the service flow identifier, verification unit number, window identifier, first-level operation identifier, first-level matrix version, and initial conserved code into an initial bypass verification record, and generates a record authentication value based on the window verification factor.

[0121] The i-th level verification module receives bypass verification records and record authentication values ​​through an independent verification channel. It associates the bypass verification records with the corresponding verification data units based on the service flow identifier and verification unit sequence number, and first matches the window identifier in the bypass verification record with the currently visible time window. When the window identifier does not match, the current verification position is determined as the cross-window replay anomaly boundary, and handled according to the method corresponding to cross-window replay anomalies. When the window identifier matches but the reception time of the verification data unit is outside the currently visible time window, the corresponding transformation conservation code and service data are invalidated. When the window identifier matches and the reception time of the verification data unit is within the currently visible time window, the i-th level verification module verifies the record authentication value. After the record authentication value verification passes, the operation identifier and matrix version are matched with the locally configured i-th level operation identifier and i-th level matrix version, respectively. When the record authentication value verification fails, the corresponding service data is not allowed to pass and a record authentication anomaly alarm is generated.

[0122] The output interface of the i-th level protocol conversion module is connected to the controlled queue to be transmitted. A hardware mirroring channel set between the output interface and the network transmission interface copies the actual output data to the i-th level verification module. The actual output data remains in the controlled queue to be transmitted until the i-th level verification module returns a release signal.

[0123] The i-th level verification module parses the actual output data according to the corresponding level semantic coordinate table, generates the actual output semantic vector, calculates the inner product of the i-th level coefficient vector and the actual output semantic vector, and takes the modulo of the calculation result with q to obtain the i-th level transform conservation code.

[0124] The i-th level verification module determines whether the difference between the i-th level transform-conserved code and the previous level transform-conserved code in the bypass verification record is equal to the sum of the i-th level coefficient vector and the permitted change vector. The inner product of.

[0125] When the record authentication value verification passes and both the inner product check and the identifier verification pass, the i-th level verification module returns a release signal to the controlled queue to be sent. If the i-th level is not the last level, it reads the i+1-th level operation identifier and matrix version from the protocol transformation sequence, encapsulates the service flow identifier, verification unit number, window identifier, i+1-th level operation identifier, i+1-th level matrix version, and i-th level transformation conservation code into the next bypass verification record, generates the corresponding record authentication value, and sends it to the i+1-th level verification module through an independent verification channel. After completing the verification, the i+1-th level verification module returns a release confirmation or verification failure result to the i-th level verification module through the independent verification channel. If the i-th level is the last level, the actual output data is sent to the target service node.

[0126] When the authentication value verification fails, the inner product verification fails, or the identifier verification fails, the i-th level verification module does not return a release signal and sets the controlled queue to be sent to a blocked state.

[0127] VI. Numerical Calculation Example of Transformation Conservation Code

[0128] To facilitate the explanation of the calculation process of the transformation conservation code, this embodiment selects the first two levels of the protocol transformation from the complete protocol transformation sequence and uses a reduced finite field of q=257 for numerical explanation. In actual deployment, the aforementioned 256-bit prime number will still be used.

[0129] The initial semantic vector sequentially includes the service flow identifier encoding value, the application process identifier, the first payload block feature value, and the second payload block feature value, with the following values:

[0130] x0 = (10, 20, 30, 40).

[0131] The first-level protocol transformation maps the application process identifier to a UDP destination port and adds a protocol type field with a value of 17. To simplify numerical calculations, this numerical example sets the default port base value to 0, so the mapped UDP destination port remains 20. The first four diagonal elements of the first-level sparse transformation matrix A1 are 1, and the remaining elements are 0. The permissible transformation vector is:

[0132] b1 = (0, 0, 0, 0, 17).

[0133] The semantic vector after the first-level protocol transformation is:

[0134] x1=(10, 20, 30, 40, 17).

[0135] The second-level protocol transformation adjusts the semantic components in the following order: service flow identifier encoded value, first payload block feature value, second payload block feature value, UDP destination port, protocol type field, and tunnel identifier, and adds a tunnel identifier with a value of 55. To simplify numerical calculations, the semantic coordinates corresponding to the address field and hop count limit field are not listed in this numerical example.

[0136] The non-zero elements in the second-level sparse transformation matrix A2 are located in the 1st row and 1st column, the 2nd row and 3rd column, the 3rd row and 4th column, the 4th row and 2nd column, and the 5th row and 5th column. The value of these non-zero elements is 1, and the values ​​of the remaining matrix elements are 0. The second-level permissible transformation vector is:

[0137] b2=(0, 0, 0, 0, 0, 55).

[0138] The semantic vector after the second-level protocol transformation is:

[0139] x2=(10, 30, 40, 20, 17, 55).

[0140] Suppose the final-order coefficient vector generated based on the window check factor is:

[0141] r2=(2, 3, 5, 7, 11, 13).

[0142] Based on the inverse calculation of the sparse transformation matrix, we obtain:

[0143] r1=(2, 7, 3, 5, 11);

[0144] r0=(2, 7, 3, 5).

[0145] The initial conserved code is calculated to be 193 on GF(257), the first-level transform conserved code is 123, and the second-level transform conserved code is 67.

[0146] The difference between the first-level transformed conserved code and the initial conserved code is 187, which equals... and The inner product; the difference between the second-level transform conserved code and the first-level transform conserved code is 201, which equals... and The inner product of the two protocols. Therefore, both-level protocol transformations pass the inner product check.

[0147] If the second-level protocol transformation module unauthorizedly changes the first payload block characteristic value from 30 to 31, then the second-level transformation conservation code changes from 67 to 70. At this point, the difference between the second-level transformation conservation code and the first-level transformation conservation code is no longer equal to... and The inner product of the two levels of protocol transformation modules is used to identify the second-level protocol transformation module as a semantic change exception module.

[0148] VII. Determination of Abnormal Modules and Boundaries, and Security Handling of Business Flow

[0149] Combination Figure 5 When the inner product check or the identifier check fails, the check control node determines the anomaly type in the following manner:

[0150] If the window identifier, operation identifier, and matrix version all pass verification, but the inner product verification fails, the current level protocol transformation module will be identified as a semantic change abnormal module.

[0151] When the operation identifiers are discontinuous or the order of the operation identifiers is inconsistent with the protocol transformation sequence, the verification position of the first bypass verification record of the received mismatched operation identifier will be determined as the transformation sequence abnormal boundary.

[0152] When the matrix version is inconsistent with the locally configured matrix version, the verification position of the first bypass verification record of the mismatched matrix version will be determined as the abnormal boundary of the transformation rule.

[0153] When the window identifier does not match the currently visible time window, the protocol transformation input boundary corresponding to the bypass verification record carrying the mismatched window identifier is determined as the cross-window replay anomaly boundary. The cross-window replay anomaly boundary is used to indicate that the business data or bypass verification record did not match the currently visible time window before entering the corresponding protocol transformation module, and the protocol transformation module is not directly identified as a faulty module.

[0154] Each verification node has a business data buffer. For business data that has been output but has not yet received confirmation of approval from the next verification node, the verification node temporarily stores it in the business data buffer according to the business flow identifier and verification unit sequence number. When the next verification node returns confirmation of approval, the corresponding cached data is deleted; when a verification failure result is returned, the corresponding cached data is retained as recovery data.

[0155] When a semantic change anomaly module, a change order anomaly boundary, or a change rule anomaly boundary is identified, the verification module located at the output end of the anomaly module or downstream of the anomaly boundary will set the corresponding output queue to a blocking state, stop forwarding business data that has not yet passed verification, and discard abnormal output data that has been generated but not yet released.

[0156] The verification control node searches upstream of the anomaly location along the protocol transformation sequence, and identifies the last verification node before the anomaly location that passes both the inner product verification and the identifier verification. When the first-level protocol transformation module is identified as a semantic change anomaly module, or when the input boundary of the first-level protocol transformation module is identified as an anomaly boundary, the entry verification module is identified as the recovery checkpoint.

[0157] The service data cache at the recovery checkpoint stores the most recently verified service data, service flow identifier, verification unit number, window identifier, previous level transformation conservation code, and corresponding bypass verification record. The verification control node selects a backup protocol transformation module from the backup module registration table that can execute the remaining protocol transformation sequence from the abnormal location, based on the operation identifier corresponding to the abnormal location in the protocol transformation sequence, the locally configured matrix version, the load status of the backup protocol transformation module, and the network connectivity status.

[0158] The recovery checkpoint, based on the saved service flow identifier, verification unit number, window identifier, and previous-level transformation conservation code, encapsulates the operation identifier corresponding to the abnormal position and the locally configured matrix version into a first-level recovery bypass verification record, and generates a record authentication value based on the window verification factor. The verification control node sends the saved service data, the first-level recovery bypass verification record, the record authentication value, and the remaining protocol transformation sequence from the abnormal position to the backup protocol transformation module.

[0159] The backup protocol transformation module loads the protocol transformation rules for each level sequentially according to the remaining protocol transformation sequence, and executes the protocol transformation level by level starting from the abnormal position. After each level of protocol transformation is completed, the output service data of that level is copied to the verification module isolated from the protocol transformation of that level through the hardware mirroring channel. The isolated verification module first verifies the window identifier in the corresponding bypass verification record. When the window identifier matches, it verifies the record authentication value. After the record authentication value is verified, it verifies the operation identifier and matrix version. Based on the actual output service data of that level, it generates the actual output semantic vector and transformation conservation code, and performs inner product verification using the previous level's transformation conservation code in the corresponding bypass verification record.

[0160] If the current level is not the last level of the remaining protocol transformation sequence and the record authentication value verification, inner product verification, and identifier verification all pass, the isolated verification module encapsulates the service flow identifier, verification unit number, window identifier, next-level operation identifier, matrix version, and the current level transformation conservation code into the next bypass verification record, generates the corresponding record authentication value, and enables the standby protocol transformation module to continue executing the next level protocol transformation. If any level verification fails, the execution of the remaining protocol transformation sequence is stopped.

[0161] When the record authentication value verification, inner product verification, and identifier verification at each level in the remaining protocol transformation sequence all pass, the verification control node releases the blocking state of the corresponding output queue, sends the service data that completes the remaining protocol transformation sequence to the target service node, and deletes the cached copy of the corresponding service data in the recovery checkpoint.

[0162] If any level of record authentication value verification, inner product check, or identifier verification fails, the output queue remains blocked, the corresponding business data generated by the backup protocol transformation module is discarded, and a new backup protocol transformation module is selected from the backup module registration table. If no backup protocol transformation module meets the conditions, the business flow remains blocked and a security alarm is generated.

[0163] When an abnormal boundary for cross-window replay is determined, the switchover of the backup protocol transformation module is not performed. The verification module discards service data with mismatched window identifiers and their corresponding bypass verification records, and sends the service flow identifier, verification unit sequence number, reception time, and mismatched window identifier to the verification control node. The verification control node suspends the corresponding service flow, updates the random number and window verification factor, regenerates the coefficient vectors at each level according to the updated window verification factor, and sends the updated window verification factor and coefficient vectors at each level to the corresponding verification module through an independent verification channel; after each verification module returns parameter reception confirmation, the bypass verification records generated using the original verification parameters in the corresponding service flow are cleared, and the corresponding service flow is restored.

[0164] After the current visible time window ends, the verification control node cancels the window verification factor and corresponding coefficient vector, and stops receiving bypass verification records carrying the original window identifier. When entering the next visible time window, the window identifier, random number, window verification factor, and coefficient vectors at all levels are regenerated, thereby avoiding adjacent visible time windows sharing the same set of verification parameters. For service data and its bypass verification records arriving outside the current visible time window, the verification module marks them as invalid and discards them, without triggering the switchover of the backup protocol transformation module.

[0165] This embodiment uses space packets, UDP / IPv6, and VXLAN to construct a protocol transformation sequence to illustrate the specific implementation process of the present invention. In other embodiments, the protocol transformation sequence may also include IPv4 to IPv6 conversion, TCP to custom transport protocol conversion, GRE encapsulation, SRv6 encapsulation, or other processes that will cause changes in protocol fields and message structure. Integrity verification can be performed according to the method disclosed in this embodiment simply by establishing a semantic coordinate table, a sparse transformation matrix, and a permissive transformation vector based on the corresponding protocol field mapping rules.

[0166] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for protecting satellite-to-ground service integrity based on transformation-conserving codes, characterized in that, include: Obtain the protocol transformation sequence and operation identifiers at each level of the satellite-to-ground service flow; The current visible time window is determined based on the satellite ephemeris and the coverage area of ​​the gateway station, and a window verification factor is generated based on the window identifier, random number, and service flow identifier. According to the preset semantic encoding rules, the feature values ​​and block identifiers of the service preservation fields, license rewrite fields, and fixed-granularity payload blocks involved in the protocol transformation at all levels are encoded into semantic vectors over the finite field GF(q). Configure sparse transformation matrices for each level of protocol transformation. Permitted change vector And matrix version, so that the expected output semantic vector of the i-th level protocol transformation is changed from the semantic vector before transformation through Linear transformation and superposition get; Generate the final-level coefficient vector based on the window check factor. And based on the transpose of the sparse transformation matrices at each level, the coefficient vectors of the remaining levels are obtained in reverse; The initial conserved code is generated by the entry verification module based on the inner product of the initial coefficient vector and the initial semantic vector; The verification module, which is set at the output end of each level of the protocol transformation module and is isolated from the module, extracts the actual output semantic vector from the actual output data according to the preset semantic encoding rules, and generates the transformation conservation code based on the inner product of the corresponding level coefficient vector and the actual output semantic vector. Determine step by step whether the difference between the current level transform conservation code and the previous level transform conservation code is equal to the inner product of the current level coefficient vector and the permitted change vector, and verify the window identifier, the operation identifier and the matrix version; The first protocol transformation module that fails the inner product check is identified as an abnormal module, the first check position that fails the identifier check is identified as an abnormal boundary, and the abnormal module or the business flow corresponding to the abnormal boundary is blocked. Where n is the protocol transformation level, i is the protocol transformation level from 1 to n, and q is a prime number.

2. The satellite-to-ground service integrity protection method according to claim 1, characterized in that, The preset semantic encoding rules include: Semantic coordinate tables for each level of protocol transformation before and after transformation are established, and mapping relationships are established between semantic coordinates corresponding to protocol fields with the same business meaning. The payload is divided into blocks according to the byte offset of the satellite-to-ground service flow rather than the protocol message boundary. Each payload block is defined as a check data unit. A check unit number is assigned to each check data unit, and the characteristic value of each payload block is calculated. The protocol field values, payload block feature values, and block identifiers are mapped to domain elements in GF(q) and written to the corresponding semantic coordinates; Fill the semantic coordinates of the optional protocol fields that are not carried by the current verification data unit in the semantic coordinate table with zeros to obtain the semantic vectors before and after the transformation of each level of protocol.

3. The satellite-to-ground service integrity protection method according to claim 2, characterized in that, The above describes configuring sparse transformation matrices for each level of protocol transformation. ,include: Use the semantic coordinates after the i-th level protocol transformation as the matrix rows, and use the semantic coordinates before the i-th level protocol transformation as the matrix columns; For semantic coordinates before and after that have a relationship of inheritance of field values ​​or load block feature values, the corresponding matrix element is configured to 1; For semantic coordinates before and after that which do not have the inheritance relationship, the corresponding matrix elements are configured to 0, so that the sparse transformation matrix Aᵢ represents the field retention, copying, reordering and deletion relationships in the corresponding protocol transformation.

4. The satellite-to-ground service integrity protection method according to claim 3, characterized in that, The configuration of permission change vectors for protocol transformation at each level is described. And matrix versions, including: Obtain the address translation parameters, encapsulation identifier, protocol type identifier, sequence adjustment parameters, and time-to-live adjustment parameters used for the i-th level protocol transformation; by This represents the semantic vector before the i-th level protocol transformation obtained according to the preset semantic encoding rules, in order to... This represents the expected output semantic vector determined at the semantic coordinate level according to the protocol field mapping rules and permission change parameters, and the permission change vector is calculated on GF(q) according to the following formula. : ; right , The matrix version is obtained by encoding the corresponding operation identifier and binding the matrix version with the current visible time window.

5. The satellite-to-ground service integrity protection method according to claim 4, characterized in that, The step of generating the final-level coefficient vector based on the window check factor, and generating coefficient vectors for each level from the final level to the first level, includes: Using the root verification key as the key material, and using the window identifier, random number, and service flow identifier as derived inputs, key derivation operations are performed to obtain the window verification factor; Using the window verification factor as the key, and the level identifier of the final-level protocol transformation and the component numbers of the final-level semantic vector as inputs, a pseudo-random operation is performed. The results of each operation are mapped to GF(q), and the components with zero values ​​in the mapping results are replaced with preset non-zero values ​​to obtain the final-order coefficient vector. ; The coefficient vectors for each level are generated sequentially from the last level to the first level according to the following formula: · 。 6. The satellite-to-ground service integrity protection method according to claim 5, characterized in that, The verification module, isolated from the protocol transformation module, extracts the actual output semantic vector from the actual output data, including: The corresponding level coefficient vector, the permitted change vector, the window verification factor, the window identifier, and the protocol transformation sequence containing operation identifiers and matrix versions at each level are received through an independent verification channel, and the received information is stored in an isolated storage area that cannot be written to by the protocol transformation module. The actual output data is obtained through a hardware mirroring channel set between the output interface of the protocol conversion module and the network transmission interface; According to the preset semantic encoding rules, the actual output data is converted into an actual output semantic vector with the same dimension as the corresponding level coefficient vector.

7. The satellite-to-ground service integrity protection method according to claim 6, characterized in that, The verification window identifier, operation identifier, and matrix version include: The entry verification module or the previous level verification module encapsulates the business flow identifier, verification unit number, window identifier, operation identifier and matrix version of the protocol transformation to be executed in the current level, and the previous level transformation conservation code into a bypass verification record, and generates a record authentication value based on the window verification factor and the bypass verification record. When the current level is the first level, the previous level transformation conservation code is the initial conservation code. The bypass verification record and the record authentication value are sent to the current-level verification module through an independent verification channel; The current-level verification module associates the bypass verification record with the corresponding verification data unit based on the service flow identifier and the verification unit sequence number. First, it matches the window identifier with the currently visible time window. When the window identifier matches and the reception time of the verification data unit is within the currently visible time window, it verifies the record authentication value. After successful verification, it matches the operation identifier and the matrix version with the locally configured current-level operation identifier and current-level matrix version, respectively. If the record authentication value verification fails, it rejects the bypass verification record and blocks the corresponding verification data unit. After the current level protocol transformation is completed, the current level transformation conservation code is generated, and the inner product check is performed using the previous level transformation conservation code in the bypass check record; When the authentication value verification is successful and both the inner product verification and the identifier verification are successful, the business data output by the current level protocol transformation module is allowed. When there is a next-level protocol transformation, the business flow identifier, the verification unit number, the window identifier, the next-level operation identifier, the matrix version, and the current level transformation conservation code are encapsulated into the next bypass verification record, the corresponding record authentication value is generated, and sent to the next-level verification module. When there is no next-level protocol transformation, the business data is sent to the target business node.

8. The satellite-to-ground service integrity protection method according to claim 1, characterized in that, The process of determining the current visible time window based on satellite ephemeris and gateway station coverage area includes: The times when the satellite enters and leaves the coverage area of ​​the gateway station are determined based on the satellite ephemeris, the location of the gateway station, and the minimum communication angle. The sum of the maximum satellite-to-ground transmission delay and the maximum relative clock error between the verification nodes is determined as the window protection duration. The current visible time window is obtained by delaying the entry time by the window protection duration and advancing the exit time by the window protection duration. Transform conservation codes and their corresponding service data that do not match the window identifier will be invalidated, and transform conservation codes and their corresponding service data received outside the currently visible time window will also be invalidated.

9. The satellite-to-ground service integrity protection method according to claim 7, characterized in that, The determination of the abnormal module or abnormal boundary includes: If the window identifier, operation identifier, and matrix version have all been verified, but the difference between the current level transformation conservation code and the previous level transformation conservation code is not equal to the inner product of the current level coefficient vector and the permitted change vector, the current level protocol transformation module will be identified as a semantic change abnormal module. When the operation identifiers are discontinuous or the order of the operation identifiers is inconsistent with the protocol transformation sequence, the verification position of the first bypass verification record that does not match the operation identifier is determined as the transformation sequence abnormal boundary. When the matrix version is inconsistent with the locally configured matrix version, the verification position of the first bypass verification record of the mismatched matrix version is determined as the abnormal boundary of the transformation rule. When the window identifier does not match the current visible time window, the verification position of the bypass verification record with the mismatched window identifier is determined as the cross-window replay anomaly boundary.

10. The satellite-to-ground service integrity protection method according to claim 9, characterized in that, Block the business flow corresponding to the abnormal module or abnormal boundary, including: The verification module at the output end of the anomaly module or the downstream side of the anomaly boundary sets the corresponding output queue to a blocking state and stops forwarding service data that has not yet passed the verification. When the anomaly type is semantic change anomaly, transformation order anomaly, or transformation rule anomaly, the nearest upstream verification node that has passed both inner product verification and identifier verification is determined as the recovery checkpoint. Among them, when the first-level protocol transformation module or its input boundary is determined as the anomaly location, the entry verification module is determined as the recovery checkpoint. Based on the operation identifier corresponding to the abnormal position in the protocol transformation sequence and the locally configured matrix version, a backup protocol transformation module capable of executing the remaining protocol transformation sequence from the abnormal position is selected; the recovery checkpoint generates a first-level recovery bypass verification record and a record authentication value based on the operation identifier corresponding to the abnormal position and the locally configured matrix version, according to the saved service flow identifier, verification unit number, window identifier, and previous-level transformation conservation code, and sends the saved service data, the first-level recovery bypass verification record, the record authentication value, and the remaining protocol transformation sequence to the backup protocol transformation module; The backup protocol transformation module executes each level of protocol transformation sequentially according to the remaining protocol transformation sequence. After each level of protocol transformation is completed, the verification module, which is isolated from the protocol transformation of that level, generates a transformation conservation code based on the actual output semantic vector of that level, verifies the record authentication value of the corresponding bypass verification record, performs inner product verification using the previous level's transformation conservation code in the corresponding bypass verification record, and verifies the window identifier, operation identifier, and matrix version. When the current level is not the last level of the remaining protocol transformation sequence and all verifications of that level pass, the next bypass verification record and its corresponding record authentication value are generated, and the next level of protocol transformation continues to be executed. When the record authentication value verification, inner product verification and identifier verification at each level in the remaining protocol transformation sequence all pass, the blocking state is lifted, and the business data that completes the remaining protocol transformation sequence is sent to the target business node. When any level of record authentication value verification, inner product verification, or identifier verification fails, the blocking state is maintained, the corresponding business data generated by the backup protocol transformation module is discarded, and a new backup protocol transformation module is selected. When the exception type is cross-window replay, the corresponding business flow is paused, business data and bypass verification records with mismatched window identifiers are discarded, the corresponding protocol transformation module remains unchanged, the random number, window verification factor and coefficient vectors at all levels are updated, and the corresponding business flow is restored after the updated verification parameters are synchronized to the verification modules at all levels.

Images