A security testing method and system for an airborne AFDX network

Abstract

The application provides a kind of security test method and system for airborne AFDX network, by the security state machine modeling of AFDX protocol stack, increase security related state and malicious input migration on the basis of normal protocol state machine, propose state guide's directional variation test case generation algorithm, different fields of AFDX frame are with differential variation rule, drive the system to be tested to reach dangerous state, and automatically determine the type of vulnerability and the level of security impact by security determination criterion engine, so as to generate the vulnerability test report conforming to the preset format (for example, DO-356A format).The application can understand the protocol semantics and behavior constraints of AFDX, systematically detect the security vulnerabilities of VL isolation, RM integrity, BAG traffic control and load processing, and is equipped with a special test device supporting accurate timing injection of AFDX frame.

Description

Technical Field

[0001] This invention relates to the field of information security testing technology, and in particular to a security testing method and system for airborne AFDX networks. Background Technology

[0002] AFDX (Avionics Full-Duplex Switched Ethernet) has become the mainstream backbone network protocol for modern civil avionics systems and is widely used in various aircraft models. Based on the ARINC 664 Part 7 standard, AFDX adds a deterministic Virtual Link (VL) communication mechanism, a Bandwidth Allocation Gap (BAG) traffic scheduling mechanism, and a Redundancy Management (RM) dual network redundancy mechanism to Ethernet, ensuring the determinism and reliability of communication.

[0003] DO-356A (Airworthiness Security Methods and Considerations) requires security testing of airborne systems, including penetration testing and vulnerability testing, to verify the system's ability to withstand information security threats. However, existing security testing methods and tools are fundamentally incompatible with the AFDX protocol environment:

[0004] (1) General security testing tools are not applicable to the AFDX protocol environment. Mature testing tools in the network security field (such as Metasploit, Nessus, and Burp Suite) are designed for the TCP / IP (Transmission Control Protocol / Internet Protocol) protocol stack. Their vulnerability exploitation modules and fuzzing engines construct test packets based on the characteristics of standard IT protocols such as HTTP (Hyper Text Transfer Protocol), SSH (Secure Shell), and DNS. Although the AFDX protocol reuses the MAC frame format at the Ethernet frame level, its upper-layer protocol semantics are completely different: Virtual Link Identifier replaces IP address as the communication identifier, BAG replaces TCP flow control as the flow scheduling mechanism, and RM's dual network redundancy replaces TCP retransmission as the reliability guarantee. General tools cannot understand these AFDX-specific protocol semantics, and therefore cannot construct targeted test cases.

[0005] (2) Traditional fuzzing is inefficient and has insufficient coverage. Applying general fuzzing methods to AFDX frames—that is, randomly mutating the fields of AFDX frames—does not require understanding the protocol semantics, but the testing efficiency is low. The effective mutation space of AFDX frames is huge (16-bit virtual link identifier, 8-bit sequence number, payload up to 1471 bytes). Most of the random mutations generate invalid frames that are discarded by the end system during the frame header parsing stage. Very few can touch the deeper processing logic of the end system (such as VL scheduling, RM integrity verification, payload semantic processing). Syntax-based fuzzing requires a protocol syntax model, but simply describing the frame format (which fields are in which positions) is insufficient to cover the behavioral semantics of AFDX (inter-frame timing relationships, sequence number continuity constraints, VL scheduling strategy).

[0006] (3) Lack of a security vulnerability model specific to the AFDX protocol. The security vulnerability model of AFDX differs from that of traditional IT networks. Typical vulnerability types in IT networks (buffer overflow, SQL injection, XSS) are largely absent in the AFDX environment because AFDX end systems do not run web services or databases. AFDX-specific vulnerabilities are more related to the implementation of the protocol mechanism: whether VL isolation is strictly enforced (whether frames with illegal virtual link identifiers are completely discarded rather than mistakenly forwarded), whether the RM's anti-replay capability is robust (whether the sequence number check window is reasonable), whether BAG traffic shaping can protect the bandwidth of legitimate VLs under abnormal traffic, and whether the end system's handling of abnormally formatted payloads is secure. Currently, there is no systematic method to define and detect these AFDX-specific security vulnerabilities. Summary of the Invention

[0007] In view of the shortcomings of the prior art described above, the purpose of this invention is to provide a security testing method and system for airborne AFDX networks to solve the technical problems existing in the prior art.

[0008] To achieve the above and other related objectives, this invention provides a security testing method for airborne AFDX networks, comprising the following steps:

[0009] The AFDX protocol specification is obtained, and a security state machine is constructed based on the protocol stack in the AFDX protocol specification. Security-related state nodes and malicious input migration edges are added to the security state machine. The security-related states include normal state, alarm state, and dangerous state. The malicious input migration edges are used to describe the state transition behavior of the AFDX end system when it receives a violation frame. The violation frame includes illegal virtual link identifier frames, replay sequence number frames, burst frames that violate bandwidth allocation table constraints, and abnormal format payload frames.

[0010] In the safety state machine, a reverse breadth-first search is performed with each dangerous state as the endpoint and the initial state as the starting point to find the shortest migration path for the AFDX end system from the initial state to the dangerous state. Each migration edge on the migration path corresponds to an input frame. Furthermore, test cases are generated by applying differential mutation rules to different fields of the AFDX input frame.

[0011] The generated test cases are injected into the network interface of the AFDX end system according to the timing requirements to capture the response behavior of the AFDX end system; and the response behavior is matched with the predefined vulnerability judgment rules through the security judgment criterion engine, and the security impact level of the successfully matched vulnerability is determined according to the design guarantee level of the function carried by the affected virtual link, and a vulnerability test report in a preset format is generated.

[0012] Optionally, the construction process of the security state machine includes:

[0013] A security state machine is established for the receiver of each AFDX end system. The initial state of the security state machine is normal reception, and it remains in the normal state when a legitimate frame is received. The legitimate frame includes frames identified by the virtual link in the configuration table, frames with consecutive sequence numbers, and frames whose frame intervals conform to the constraints of the bandwidth allocation table.

[0014] Define alarm state transitions, including: transitioning to illegal virtual link alarm state when a frame with a virtual link identifier not in the configuration table is received; transitioning to sequence number abnormal alarm state when a frame with a non-contiguous sequence number is received; and transitioning to traffic over-limit alarm state when a frame with a frame interval less than the minimum value in the bandwidth allocation table is received.

[0015] Define dangerous state transitions, including: if the AFDX end system receives and processes the corresponding frame under the illegal virtual link alarm state, it will transition to the virtual link isolation failure dangerous state; if it receives a replay frame under the sequence number abnormal alarm state, it will transition to the anti-replay failure dangerous state; if it continuously receives excessive traffic causing the frames of the legitimate virtual link to be dropped, it will transition to the denial-of-service dangerous state.

[0016] Optionally, the differential variation rules include virtual link identifier field variation, sequence number field variation, payload field variation, and frame interval variation;

[0017] The virtual link identifier field variation is used to select a virtual link identifier value from outside the virtual link configuration table of the AFDX end system, construct a cross-virtual link injection frame, and keep other fields of the frame valid, in order to test whether the AFDX end system filters illegal frames only based on the virtual link identifier; among them, other fields include MAC address and Ethernet type;

[0018] The sequence number field is mutated to record the sequence number sequence in normal communication of the AFDX end system, and to construct replay frames, out-of-order frames and skip frames to test the redundancy management mechanism of the AFDX end system to detect various sequence number anomalies.

[0019] The payload field variation is used to parse the data format constraints of the application protocol in the AFDX frame payload. It injects boundary values ​​and out-of-range values ​​into the numerical field, undefined enumerated values ​​into the enumerated field, and values ​​that do not match the actual payload into the length field. Among them, the boundary values ​​include the maximum value, minimum value, and zero value.

[0020] Frame interval variation is used to construct burst traffic sequences that violate bandwidth allocation table constraints. More frames than the configured allowable number are sent within the bandwidth allocation table period, gradually increasing from single-frame bursts to continuous bursts, in order to test the traffic shaping mechanism of the AFDX end system and its ability to protect legitimate virtual link frames under burst traffic.

[0021] Optionally, the replay frame represents a frame using a sequence number that has already appeared, the out-of-order frame represents a frame using a non-incrementing sequence number, and the skipped frame represents a frame using a sequence number greater than the current value.

[0022] Optionally, the method further includes:

[0023] When searching for the shortest migration path, for dangerous states requiring multiple migration steps to reach, the input frame sequence is constructed sequentially according to the migration edges on the migration path. The construction of each input frame is based on the triggering conditions of the migration edges and the current state of the AFDX end system; and,

[0024] In cases where multiple migration paths lead to the same dangerous state, the migration paths are sorted from shortest to longest. Test cases are generated first for the shortest migration path, and then test cases for the other migration paths are generated.

[0025] Optionally, the security determination criteria include: virtual link isolation failure determination, anti-replay failure determination, denial-of-service determination, and payload processing anomaly determination;

[0026] The virtual link isolation failure determination is used to determine the vulnerability of virtual link isolation when the upper layer application of the AFDX end system receives payload data of illegal virtual link identification frame. The security impact level is the highest design guarantee level among all legal virtual links on the AFDX end system.

[0027] The anti-replay failure determination is used to determine the vulnerability of the anti-replay mechanism when the AFDX end system fails to detect replay frames.

[0028] Denial-of-service determination is used to identify a vulnerability as a denial-of-service vulnerability when a sudden surge in traffic causes the AFDX end system to drop frames from legitimate virtual links within a bandwidth allocation table period and the frame drop rate exceeds a preset threshold.

[0029] The payload processing anomaly determination is used to determine payload processing vulnerability when semantically mutated frames cause abnormal behavior in the upper-layer application of the AFDX end system. The security impact level is taken as the design guarantee level of the application function. Abnormal behavior includes crashes, out-of-range output values, or response timeouts.

[0030] Optionally, the rules for generating vulnerability test reports include:

[0031] For each discovered vulnerability, record the test case number that triggered the vulnerability, the variant field type, the variant value, the end system response behavior, and the judgment result;

[0032] The security impact level is determined based on the design assurance level and vulnerability type of the functions carried by the affected virtual links: the impact level of virtual link isolation failure and denial-of-service vulnerability is directly taken as the DAL level of the affected function, and the impact level of replay failure vulnerability is reduced by one level based on the DAL level of the affected function.

[0033] For each vulnerability, a remediation recommendation is generated according to its impact level: vulnerabilities affected by DAL A and DAL B are marked as requiring remediation, vulnerabilities affected by DAL C are marked as requiring remediation, and vulnerabilities affected by DAL D and DAL E are marked as subject to risk review.

[0034] This invention also provides a security testing system for airborne AFDX networks, the system comprising:

[0035] The security state machine modeling module is used to obtain the AFDX protocol specification, construct a security state machine based on the protocol stack in the AFDX protocol specification, and add security-related state nodes and malicious input migration edges to the security state machine. The security-related states include normal state, alarm state, and dangerous state. The malicious input migration edges are used to describe the state transition behavior of the AFDX end system when it receives a violation frame. The violation frame includes illegal virtual link identifier frames, replay sequence number frames, burst frames that violate bandwidth allocation table constraints, and abnormal format payload frames.

[0036] The state-guided mutation test module is used to perform a reverse breadth-first search in the safety state machine with each dangerous state as the endpoint and the initial state as the starting point to find the shortest migration path for the AFDX end system from the initial state to the dangerous state. Each migration edge on the migration path corresponds to an input frame. The module also generates test cases by applying differential mutation rules to different fields of the AFDX input frame.

[0037] The security assessment and reporting module is used to inject the generated test cases into the network interface of the AFDX end system according to the timing requirements, capture the response behavior of the AFDX end system, and match the response behavior with the predefined vulnerability assessment rules through the security assessment criterion engine. Based on the design assurance level of the function carried by the affected virtual link, the module determines the security impact level of the successfully matched vulnerability and generates a vulnerability test report in a preset format.

[0038] Optionally, the system further includes an AFDX interface module, which includes an AFDX physical interface supporting dual redundant networks, for connecting network A and network B of the AFDX end system, and providing frame injection and frame listening functions.

[0039] Optionally, the system further includes: a real-time frame generation and injection module, used to generate AFDX input frames in real time according to the frame content and timing parameters specified in the test cases;

[0040] The response capture and analysis module is used to capture the network response frames and interface behavior of the AFDX end system after receiving the test frame, record the frame timestamp and content, and transmit the capture results to the host computer.

[0041] As described above, this invention provides a security testing method and system for airborne AFDX networks, which has the following beneficial effects: By modeling the AFDX protocol stack as a security state machine, adding security-related states and malicious input migrations to the normal protocol state machine, a state-guided directed mutation test case generation algorithm is proposed. Differentiated mutation rules are applied to different fields of AFDX frames to drive the tested system to a dangerous state. A security judgment criterion engine automatically determines the vulnerability type and security impact level, thereby generating a vulnerability test report conforming to a preset format (e.g., DO-356A format). This invention can understand the protocol semantics and behavioral constraints of AFDX, systematically detect security vulnerabilities in VL isolation, RM integrity, BAG flow control, and payload processing, and is equipped with a dedicated testing device that supports precise timing injection of AFDX frames. Attached Figure Description

[0042] Figure 1 This is a schematic diagram of the security state machine of the AFDX terminal system receiver provided in one embodiment of the present invention;

[0043] Figure 2 This is a schematic diagram of the differential mutation rules and test case generation process provided in one embodiment of the present invention;

[0044] Figure 3 This is a schematic diagram of a security determination and vulnerability classification process provided in one embodiment of the present invention;

[0045] Figure 4 This is a schematic diagram comparing the efficiency of state-guided mutation testing and random fuzzy testing according to an embodiment of the present invention;

[0046] Figure 5 This is a schematic diagram of the hardware structure of a security testing system for airborne AFDX networks provided in one embodiment of the present invention. Detailed Implementation

[0047] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that, unless otherwise specified, the following embodiments and features described therein can be combined with each other.

[0048] It should be noted that the illustrations provided in this embodiment are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0049] In the field of airborne network security verification and airworthiness compliance assessment for civil aircraft, protocol-level in-depth security testing of airborne full-duplex switched Ethernet (AFDX) networks is a crucial step in ensuring the overall security of avionics systems. As the backbone network of modern advanced civil aircraft (such as the A380, A350, B787, and C919), the airborne AFDX network carries the data transmission tasks of critical avionics systems such as flight control, navigation, and display. According to the requirements of the airworthiness security standard DO-356A (Airworthiness Security Methods and Considerations), systematic network security robustness and vulnerability testing of airborne systems must be conducted to verify the system's ability to resist information security threats. However, there is a mismatch between relevant security testing methods and tools and the airborne AFDX network environment, resulting in low testing efficiency and difficulty in accessing the deep protocol processing logic of the end system.

[0050] To address the aforementioned technical problems, an exemplary embodiment of the present invention provides a security testing method for airborne AFDX networks, comprising the following steps:

[0051] S110, obtain the AFDX protocol specification, and build a security state machine based on the protocol stack in the AFDX protocol specification, and add security-related state nodes and malicious input migration edges to the security state machine; among them, security-related states include normal state, alarm state and dangerous state, and malicious input migration edges are used to describe the state transition behavior of the AFDX end system when it receives a violation frame. Violation frames include illegal virtual link identifier frames, replay sequence number frames, burst frames that violate bandwidth allocation table constraints and abnormal format payload frames.

[0052] S120: In the safety state machine, perform a reverse breadth-first search with each dangerous state as the endpoint and the initial state as the starting point to find the shortest migration path for the AFDX end system from the initial state to the dangerous state. Each migration edge on the migration path corresponds to an input frame. Additionally, generate test cases by applying differential mutation rules to different fields of the AFDX input frame.

[0053] S130: The generated test cases are injected into the network interface of the AFDX end system according to the timing requirements to capture the response behavior of the AFDX end system; and the response behavior is matched with predefined vulnerability judgment rules through the security judgment criterion engine, and the security impact level of the successfully matched vulnerability is determined according to the design assurance level of the function carried by the affected virtual link, generating a vulnerability test report conforming to a preset format. In some examples, the preset format may be DO-356A format.

[0054] In some exemplary embodiments, the process of constructing the security state machine in step S110 may include: establishing a security state machine for the receiver of each AFDX end system, with the initial state of the security state machine being normal reception, and maintaining the normal state when a legitimate frame is received; wherein, a legitimate frame includes a frame whose Virtual Link Identifier (VL ID) is in the configuration table, a frame with consecutive sequence numbers, and a frame interval that conforms to the constraints of the Bandwidth Allocation Table (BAG); defining alarm state transitions, including: transitioning to an illegal virtual link alarm state when a frame whose virtual link identifier is not in the configuration table is received, transitioning to a sequence number abnormal alarm state when a frame with a non-consecutive sequence number is received, and transitioning to a traffic over-limit alarm state when a frame with a frame interval less than the minimum value of the bandwidth allocation table is received; defining dangerous state transitions, including: if the AFDX end system accepts and processes the corresponding frame in the illegal virtual link alarm state, then transitioning to a virtual link isolation failure dangerous state; if a replay frame is accepted in the sequence number abnormal alarm state, then transitioning to an anti-replay failure dangerous state; if excessive traffic is continuously received, causing legitimate virtual link frames to be discarded, then transitioning to a denial-of-service dangerous state. Therefore, the safety state machine provides clear test completeness criteria (whether all hazardous states are covered), and the test coverage can be quantified (number of tested hazardous states / total number of hazardous states), meeting the DO-356A requirements for test adequacy.

[0055] In some examples, such as Figure 1 As shown, taking a typical AFDX end-system receiver as an example, the construction process of the secure state machine is illustrated. The AFDX end-system under test is configured with four virtual links, denoted as VL100, VL200, VL300, and VL400, with corresponding BAGs of 4ms, 8ms, 16ms, and 32ms, respectively. The secure state definitions are shown in Table 1, and some state transition rules are shown in Table 2.

[0056] Table 1 Definition of Safety Status

[0057]

[0058] Table 2. State Transition Rules (Partial)

[0059]

[0060] / * AFDX End System Receiver Security State Machine Definition * / / / This code segment implements the core data structure of the security state machine modeling module, defining all states and state transition rules of the AFDX end system receiver under the three security levels of normal, alarm, and danger.

[0061] typedef enum { / / Defines the security state enumeration type SecurityState, which contains all 14 states in the AFDX end system receiver's security state machine, grouped into three security levels: normal state, alarm state, and dangerous state.

[0062] STATE_NORMAL_RECV = 0, / / S0: Normal receiving state, which is the initial state of the security state machine. It indicates that the end system is currently in a normal state of idle waiting to receive frames. It will also return to this state after each valid frame is processed.

[0063] / * S0: Normal reception * /

[0064] STATE_PARSE_HEADER, / / S1: Frame header parsing status, indicating that the end system has received an Ethernet frame and is parsing the frame header fields (destination MAC, source MAC, EtherType), which is the first step in all frame processing.

[0065] / * S1: Frame header parsing * /

[0066] STATE_VL_MATCH, / / S2: VL matching status, indicating that the frame header parsing backend system is matching the VL ID in the frame with the local VL configuration table to determine whether the frame belongs to a legitimate virtual link received by the local system.

[0067] / * S2: VL Matching * /

[0068] STATE_SEQ_CHECK, / / S3: Sequence number verification status, indicating that the VL ID match is successful and the backend system is checking whether the SequenceNumber of the frame is continuously increasing with the previous frame through the redundancy management (RM) module.

[0069] / * S3: Serial Number Verification * /

[0070] STATE_BAG_CHECK, / / S4: BAG check status, indicating that the sequence number verification has passed and the backend system is checking whether the arrival time interval between this frame and the previous frame on the same VL meets the minimum interval constraint of the Bandwidth Allocation Table (BAG).

[0071] / * S4: BAG check * /

[0072] STATE_PAYLOAD_FWD, / / S5: Payload forwarding status, indicating that all protocol layer checks are being performed by the backend system, which is forwarding the frame payload data to the upper layer application (such as ARINC 653 partition application) for processing.

[0073] / * S5: Payload Forwarding * /

[0074] STATE_ALERT_VL, / / A1: Illegal VL alarm state, indicating that the end system found that the VL ID in the frame was not in the local VL configuration table during the VL matching stage. This is an alarm level state. The correct end system implementation should discard the frame and return to S0.

[0075] / * A1: Illegal VL alert * /

[0076] STATE_ALERT_SEQ, / / A2: Sequence number abnormal alarm status, indicating that the end system found that the SequenceNumber of the frame was discontinuous (there was a jump, backtracking or repetition) during the sequence number verification stage, which is an alarm level status.

[0077] / * A2: Serial Number Abnormality Alarm * /

[0078] STATE_ALERT_BAG, / / A3: Traffic over-limit alarm status, indicating that the end system found that the frame interval was less than the minimum BAG value configured for this VL during the BAG check phase, that is, the sending rate exceeded the allowed bandwidth limit.

[0079] / * A3: Traffic Exceedance Alert * /

[0080] STATE_ALERT_PAYLOAD, / / A4: Load anomaly alarm status, indicating that the end system found that the load length or format does not conform to the data format constraints of the upper layer protocol during the load forwarding phase, which is an alarm level status.

[0081] / * A4: Load Anomaly Alarm * /

[0082] STATE_DANGER_VL_LEAK, / / D1: VL isolation failure dangerous state, indicating that the end system did not correctly discard the frame in the A1 (illegal VL alarm) state but instead accepted and processed it, causing the VL isolation mechanism to fail, which is the most dangerous state with the highest security level.

[0083] / * D1: VL isolation failed * /

[0084] STATE_DANGER_REPLAY, / / D2: Anti-replay failure dangerous state, indicating that the end system accepted the replay frame instead of rejecting it in the A2 (sequence number abnormal alarm) state. The RM module did not effectively detect the sequence number duplication, and attackers can use this to replay old data.

[0085] / * D2: Replay protection failure * /

[0086] STATE_DANGER_DOS, / / D3: Denial of Service Dangerous State, indicating that continuous excessive traffic (A3 state) has caused the end system's frame buffer to saturate, resulting in the discarding of valid VL frames and impairing normal communication functions.

[0087] / * D3: Denial of Service * /

[0088] STATE_DANGER_CRASH / / D4: Load processing crash danger state, indicating that abnormal load (A4 state) causes the upper layer application to crash, output out-of-range values ​​or respond to timeouts, etc., affecting the normal execution of the load function.

[0089] / * D4: Load processing crash * /

[0090] } SecurityState; / / The enumeration is defined, with a total of 14 states: 6 normal states (S0-S5), 4 alarm states (A1-A4), and 4 dangerous states (D1-D4), covering the security behavior of the entire frame processing process at the AFDX end system receiver.

[0091] typedef struct { / / Defines the Transition structure, which describes the complete information of a state transition edge in a safe state machine, including the source state, target state, input type, and transition condition.

[0092] SecurityState from; / / The source state of the migration, representing the security state of the end system before the migration is performed. The value can be any state in the SecurityState enumeration.

[0093] SecurityState to; / / The target state for migration, indicating the security state that the end system will move to after the migration conditions are met, such as migrating from A1 (illegal VL alarm) to D1 (VL isolation failure).

[0094] int input_type; / / Input frame type identifier, represented by an integer encoding to indicate the input frame feature category required to trigger the migration (e.g., 0=valid frame, 1=illegal VL frame, 2=replay frame, 3=burst frame, 4=abnormal payload frame).

[0095] char condition

[128] ; / / Migration condition description string, describing the detailed triggering conditions of the migration in human-readable text, such as "VL ID is not in the configuration table" or "frame interval is less than the BAG lower limit", used for state machine visualization and report output.

[0096] } Transition; / / The structure is now defined. Each Transition instance corresponds to a directed edge in the safe state machine graph. All Transition instances constitute the complete set of transition relationships for the safe state machine.

[0097] / * Security Level Determination * / / / The following function determines the security level of any security state, mapping 14 states to three levels: Normal (0), Alarm (1), and Danger (2).

[0098] int get_security_level(SecurityState s) { / / Function definition: The input parameter s is the current security state enumeration value, and the return value is the security level corresponding to the state (0=normal, 1=alarm, 2=danger)

[0099] if (s <= STATE_PAYLOAD_FWD) return 0; / / If the status value is less than or equal to S5 (payload forwarding), it means the status is within the range of S0 to S5, which belongs to the normal status group. Returning security level 0 indicates normal.

[0100] / * normal* /

[0101] if (s <= STATE_ALERT_PAYLOAD) return 1; / / If the status value is less than or equal to A4 (load abnormality alarm), it means that the status is within the range of A1 to A4 and belongs to the alarm status group. Returning safety level 1 indicates an alarm.

[0102] / * Alert * /

[0103] return 2; / / The remaining states (D1 to D4) belong to the dangerous state group. Returning to security level 2 indicates danger, which means that the security mechanism of the end system has been breached.

[0104] / * Danger* /

[0105] } / / After the function finishes execution, the returned security level is used to indicate the security level of the real-time monitoring system during the test, as well as to mark the level classification of each dangerous state in the vulnerability report.

[0106] In some exemplary embodiments, the differential mutation rules in step S120 include virtual link identifier field mutation, sequence number field mutation, payload field mutation, and frame interval mutation. Specifically, virtual link identifier field mutation is used to select a virtual link identifier value from outside the virtual link configuration table of the AFDX end system, construct a cross-virtual link injection frame, and maintain the validity of other fields of the frame to test whether the AFDX end system filters illegal frames solely based on the virtual link identifier; wherein, other fields include MAC (Media Access Control, MAC) address and Ethernet type. Sequence number field mutation is used to record the sequence number sequence in normal communication of the AFDX end system and construct replay frames, out-of-order frames, and skip frames to test the redundancy management mechanism of the AFDX end system's ability to detect various sequence number anomalies. Payload field mutation is used to parse the data format constraints of the application protocol in the AFDX frame payload, inject boundary values ​​and out-of-range values ​​in numerical fields, inject undefined enumerated values ​​in enumerated fields, and inject values ​​that do not match the actual payload in the length field; wherein, boundary values ​​include maximum, minimum, and zero values. Frame interval mutation is used to construct burst traffic sequences that violate bandwidth allocation table constraints. It sends more frames than the configured allowable number within the bandwidth allocation table period, gradually increasing from single-frame bursts to continuous bursts, to test the AFDX end system's traffic shaping mechanism and its ability to protect legitimate virtual link frames under burst traffic. Specifically, replay frames use sequences with previously encountered sequence numbers, out-of-order frames use non-incrementing sequence numbers, and skipped frames use sequence numbers greater than the current value. This demonstrates that the differentiated mutation rules are designed specifically for the unique mechanisms of the AFDX protocol. VL ID mutation tests VL isolation robustness, sequence number mutation tests RM replay resistance, and frame interval mutation tests BAG flow control effectiveness—each mutation corresponds to a core security mechanism of the AFDX protocol, ensuring the tests cover all major categories of AFDX-specific vulnerabilities.

[0107] In some exemplary embodiments, when searching for the shortest migration path, a reverse breadth-first search is used in the safe state machine with each dangerous state as the endpoint to find the shortest migration path from the initial state to that dangerous state. Each edge on the path corresponds to a trigger condition, i.e., the required input frame feature. For dangerous states that require multiple migration steps to reach, the input frame sequence is constructed sequentially according to the order of the migration edges on the migration path. The construction of each input frame is based on the trigger condition of the migration edge and the current state of the AFDX end system. Furthermore, when multiple migration paths reach the same dangerous state, the migration paths are sorted from shortest to longest, and test cases corresponding to the shortest migration path are generated first, followed by test cases for other migration paths. Thus, the test case generation is goal-oriented rather than blind. The state-guided mutation algorithm reversely derives the input sequence with the dangerous states in the safe state machine as the target. Each generated test case has a clear test objective (reaching a specific dangerous state), avoiding a large number of invalid test cases in random fuzz testing.

[0108] In some examples, the differential mutation rules and test case generation process can be as follows: Figure 2 As shown in Table 3, the results of the dangerous state path analysis are shown in Table 4, the generated differential mutation test cases (VL ID field - cross-VL injection mutation) are shown in Table 5, the generated differential mutation test cases (sequence number field - replay / out-of-order mutation) are shown in Table 6, and the generated differential mutation test cases (frame interval - temporal mutation) are shown in Table 6.

[0109] Table 3. Results of Hazardous Path Analysis

[0110]

[0111] Table 4. Generation of Differentiated Mutation Use Cases (VL ID Field - Cross-VL Injection of Mutations)

[0112]

[0113] Table 5. Generation of Differentiated Mutation Test Cases (Sequence Number Field - Replay / Out-of-Order Mutation)

[0114]

[0115] Table 6. Generation of Differentiated Variant Use Cases (Frame Interval - Temporal Variant)

[0116]

[0117] / * State-guided mutation test case generation * / / / This code segment implements the core logic of the state-guided mutation test module, including test case data structure definition, VL isolation test case generation, and frame interval timing mutation test case generation.

[0118] typedef struct { / / Defines the TestCase structure, which describes all controllable parameters of a complete AFDX test frame. Each TestCase instance corresponds to a test frame to be injected into the system under test.

[0119] uint16_t vl_id; / / Virtual link identifier field, a 16-bit unsigned integer, with a value range of 0x0000 to 0xFFFF, corresponding to the VL ID field in the AFDX frame that identifies the virtual link to which the frame belongs.

[0120] uint8_t seq_num; / / Sequence number field, an 8-bit unsigned integer, ranging from 0 to 255, corresponding to the SequenceNumber field used by the Redundancy Management (RM) module in the AFDX frame.

[0121] uint32_t frame_interval_us; / / Frame interval field, a 32-bit unsigned integer in microseconds, specifying the transmission time interval between the test frame and the previous frame, executed by the FPGA frame injection engine with microsecond-level precision.

[0122] / * Frame interval (microseconds) * /

[0123] uint8_t payload

[1471] ; / / Payload field, byte array, maximum length 1471 bytes (maximum allowed length of AFDX frame payload), stores the payload data content of the test frame, and may contain upper-layer protocol data with semantic variations.

[0124] uint16_t payload_len; / / Actual payload length, a 16-bit unsigned integer that specifies the number of bytes of valid data in the payload array and is used to determine the total length of the Ethernet frame during frame generation.

[0125] int mutation_type; / / Mutation type identifier, an integer value indicating which field of the AFDX frame this test case mutated: 0 = VL ID field mutation, 1 = sequence number field mutation, 2 = frame interval timing mutation, 3 = payload field mutation.

[0126] / * 0=VL, 1=SEQ, 2=TIMING, 3=PAYLOAD * /

[0127] } TestCase; / / The structure is now defined. Each TestCase instance contains all the parameters required to construct a complete AFDX test frame. These parameters are filled in by the mutation generation algorithm and then passed to the FPGA frame injection engine for execution.

[0128] / * Derive the input sequence to reach the dangerous state D1 from the safe state machine * / / / The following function generates directional mutation test cases for the dangerous state D1 (VL isolation failure), and tests the VL isolation mechanism of the end system by constructing an illegal VL ID frame.

[0129] int generate_vl_isolation_tests(TestCase tests[], / / Function definition: The first parameter tests is an array of output test cases used to store all generated VL isolation test frames.

[0130] int max_tests, / / The second parameter max_tests is the maximum capacity of the test case array to prevent array out-of-bounds errors.

[0131] uint16_t valid_vls[], / / The third parameter valid_vls is an array of all valid VL IDs in the VL configuration table of the tested end system, extracted from the end system configuration file.

[0132] int vl_count) { / / The fourth parameter vl_count is the length of the valid VL ID array, that is, the total number of virtual links configured in the tested system.

[0133] int tc = 0; / / Initialize the test case counter to 0. The counter increments by 1 for each subsequent test case generated. The final return value is the total number of test cases generated.

[0134] / * Baseline: Valid VL ID * / / / First, generate baseline test cases, send normal frames using valid VL IDs, and verify that the end system maintains normal S0 reception state under normal input.

[0135] tests[tc].vl_id = valid_vls[0]; / / Set the VL ID of the baseline test case to the first valid VL ID value in the configuration table to ensure that the frame can pass the VL matching check of the end system.

[0136] tests[tc].mutation_type = 0; / / Mark the mutation type as 0 (VL ID field mutation category), so that even if the baseline test case itself has not been mutated, it is classified into the VL ID test group for unified management.

[0137] tc++; / / Increment the test case counter by 1, pointing to the next available array position.

[0138] / * Illegal VL ID: Nearest neighbor value outside the configuration table * / / / The following loop generates illegal VL ID test cases, selects VL ID values ​​not in the configuration table, and tests whether the end system strictly filters illegal frames according to the configuration table.

[0139] for (uint16_t vl = 1; vl <= 0xFFFF && tc < max_tests; vl++) { / / Iterate through the entire 16-bit VL ID space starting from VL ID value 1 (maximum 0xFFFF), while checking that the number of test cases does not exceed the array capacity limit.

[0140] int found = 0; / / Initialize the search flag to 0 to indicate whether the VL ID value being traversed exists in the valid configuration table.

[0141] for (int i = 0; i < vl_count; i++) { / / The inner loop iterates through the valid VL ID configuration table, comparing the current VL ID value with a valid VL ID one by one.

[0142] if (vl == valid_vls[i]) { found = 1; break;} / / If the current VL ID is equal to a valid VL ID in the configuration table, set the found flag to 1 and break out of the inner loop. This VL ID is not used for testing.

[0143] / / The inner loop ends. found = 1 indicates that the current VL ID is a valid value, and found = 0 indicates that the current VL ID is not in the configuration table and is an invalid value.

[0144] if (!found) { / / If found is 0, it means that the current VL ID is not in the valid configuration table. It is a valid invalid VL ID test value, which is used to construct a cross-VL injection test frame.

[0145] tests[tc].vl_id = vl; / / Write the illegal VL ID value to the vl_id field of the current test case. After this frame is injected, it is expected to trigger the end system to migrate from S2 to A1 (illegal VL alarm) state.

[0146] tests[tc].mutation_type = 0; / / Mark the mutation type as 0 (VL ID field mutation), indicating that this test case is a cross-link injection mutation test case targeting the VL isolation mechanism.

[0147] tc++; / / Increment the test case counter by 1, preparing to write the next test case.

[0148] if (tc >= 5) break; / / Limit the number of illegal VL ID test cases to no more than 5. Selecting the smallest nearest neighbor values ​​outside the configuration table can cover the boundary behavior of the VL matching logic.

[0149] / * Retrieve the first 5 invalid values ​​* /

[0150] / / End of conditional block. If the current VL ID is a valid value, skip to continue iterating over the next VL ID.

[0151] / / The outer loop has ended. Up to 5 invalid VLID values ​​not in the configuration table have been selected from the VLID space as test cases.

[0152] / * Boundary values: VL ID = 0x0000 and 0xFFFF * / / / The following two lines generate boundary value test cases for the VL ID field, testing the system's handling behavior for extreme VL ID values ​​(minimum and maximum values).

[0153] tests[tc].vl_id = 0x0000; / / Construct a test frame with a VL ID of 0x0000 (minimum boundary value) to test whether the end system correctly rejects frames with a VL ID of zero (zero value is usually not a valid VL ID).

[0154] tests[tc++].mutation_type = 0; / / Marks the mutation type as 0 (VL ID field mutation) and increments the counter by 1. This expression performs both marking and incrementing operations.

[0155] tests[tc].vl_id = 0xFFFF; / / Construct a test frame with VL ID equal to 0xFFFF (maximum boundary value, i.e., the upper limit of a 16-bit unsigned integer of 65535). This is the test system's handling of the upper bound of VL ID.

[0156] tests[tc++].mutation_type = 0; / / Mark the mutation type as 0 (VL ID field mutation) and increment the counter by 1.

[0157] return tc; / / Returns the total number of VL isolation test cases generated, including 1 baseline test case, up to 5 illegal nearest neighbor test cases, and 2 boundary value test cases.

[0158] } / / After the function finishes execution, the generated test case set covers three types of scenarios for VL ID field mutation: baseline, illegal value, and boundary value, corresponding to the path S0→S1→S2→A1→D1 in the safety state machine to reach the dangerous state D1.

[0159] / * Frame Interval Timing Variation Generation * / / / The following function generates frame interval timing variation test cases for the D3 (Denial of Service) dangerous state. It tests the system's traffic shaping capabilities by constructing burst traffic that violates BAG constraints.

[0160] int generate_timing_tests(TestCase tests[], / / Function definition: The first parameter tests is an array of output test cases used to store the generated frame interval variation test frames.

[0161] uint32_t bag_us) { / / The second parameter bag_us is the BAG value (in microseconds) configured for the virtual link under test, which is the minimum frame interval allowed by the VL. For example, if the BAG of VL100 is 4ms, then bag_us=4000.

[0162] int tc = 0; / / Initialize the test case counter to 0.

[0163] uint32_t intervals[] = { / / Defines an array of frame interval test values, containing 5 progressively decreasing temporal variation levels, from the normal value equal to BAG to the extreme burst value.

[0164] bag_us, / / The first interval is equal to the BAG value itself, serving as a baseline test case to verify the normal processing behavior of the end system under the compliant frame interval.

[0165] / * Equals BAG * /

[0166] bag_us / 2, / / The second interval is equal to half of the BAG value, that is, the sending rate is twice the configured allowable, which is a slight violation of the BAG constraint and the test system's traffic over-limit detection threshold.

[0167] / * BAG / 2 * /

[0168] bag_us / 8, / / The third interval is equal to one-eighth of the BAG value, i.e., 8 times the rate burst, which is a moderate violation of the BAG constraint. This tests whether the end system starts to drop valid VL frames under high burst traffic.

[0169] / * BAG / 8 * /

[0170] bag_us / 40, / / The fourth interval is equal to one-fortieth of the BAG value, that is, 40 times the rate of extreme burst, severely violating the BAG constraint, and testing the degree of behavior degradation of the end system under extreme attack traffic.

[0171] / * Extreme emergencies * /

[0172] bag_us / / The fifth interval is still equal to the BAG value but is marked as continuous load mode (100 frames are continuously sent without interruption during test execution) to test the risk of frame buffer exhaustion under long-term continuous load.

[0173] / * Continuous load * /

[0174] }; / / The frame interval array is now defined, and the five test values ​​cover the complete burst traffic gradient from compliance to extreme violations.

[0175] for (int i = 0; i < 5; i++) { / / Iterate through 5 frame interval test values ​​and generate a corresponding test case for each value.

[0176] tests[tc].frame_interval_us = intervals[i]; / / Write the current frame interval value to the frame_interval_us field of the test case. The FPGA frame injection engine will send test frames at this precise microsecond interval.

[0177] tests[tc].mutation_type = 2; / / Mark the mutation type as 2 (frame interval temporal mutation) to distinguish it from VL ID mutation (0) and sequence number mutation (1) for easy classification and analysis of test results.

[0178] tc++; / / Increment the test case counter by 1, preparing to write the next test case.

[0179] / / Loop ends, all 5 frame interval variation test cases have been generated.

[0180] return tc; / / Returns the total number of generated time-series variation test cases (fixed to 5). These test cases correspond to the path S0→S1→S2→S3→S4→A3→D3 in the safe state machine leading to the dangerous state D3.

[0181] / / After the function finishes executing, the generated test cases will drive the end system from the normal state through the BAG check phase to the traffic over-limit alarm A3, and finally reach the denial-of-service dangerous state D3 through continuous bursts.

[0182] In some exemplary embodiments, the security assessment criteria include: virtual link isolation failure assessment, replay failure assessment, denial-of-service assessment, and payload processing anomaly assessment. The virtual link isolation failure assessment determines a vulnerability when an upper-layer application on the AFDX end system receives payload data containing an illegal virtual link identifier frame. The security impact level is the highest design guarantee level among all legitimate virtual links on the AFDX end system. The replay failure assessment determines a vulnerability due to a lack of replay mechanisms when the AFDX end system fails to detect replay frames (the redundancy management module does not trigger a sequence number anomaly alarm and the frame is forwarded normally to the upper layer). The denial-of-service assessment determines a vulnerability when burst traffic causes the AFDX end system to drop frames from legitimate virtual links within a bandwidth allocation table period, and the frame drop rate exceeds a preset threshold. The payload processing anomaly assessment determines a vulnerability when semantically mutated frames cause abnormal behavior in the upper-layer application of the AFDX end system. The security impact level is the design guarantee level of the application's functionality; abnormal behavior includes crashes, out-of-range output values, or response timeouts. Therefore, the security assessment criteria engine provides automated vulnerability identification and classification, eliminating the need for manual analysis of test results. The automatic correlation between assessment criteria and security impact levels allows test reports to be directly used for DO-356A compliance reviews.

[0183] In some exemplary embodiments, the rules for generating vulnerability test reports include: recording the test case number that triggers the vulnerability, the mutation field type, the mutation value, the end system response behavior, and the judgment result for each discovered vulnerability. The security impact level is determined based on the design assurance level (DAL) of the function carried by the affected virtual link and the vulnerability type: the impact level of virtual link isolation failure and denial-of-service vulnerabilities is directly taken as the DAL level of the affected function; the impact level of replay failure vulnerabilities is reduced by one level from the DAL level of the affected function (because the impact of a single replay frame is usually lower than that of a persistent attack). Remediation recommendations are generated for each vulnerability according to its impact level: vulnerabilities affected by DAL A and DAL B are marked as requiring remediation, those affected by DAL C are marked as requiring remediation, and those affected by DAL D and DAL E are marked as requiring risk review. DAL (Design Assurance Level) is a classification of five security levels (A–E) in the aviation airworthiness system based on the potential impact of functional failures on flight safety, originating from the ARP4754A / ARP4761 standard, used to enforce the rigor of software and hardware development processes.

[0184] In some examples, the security determination and vulnerability classification process is as follows: Figure 3As shown in Table 7, the system configuration of the tested system is shown in Table 7, the test results and judgments are shown in Table 8, and the vulnerability summary is shown in Table 9.

[0185] Table 7 System configuration of the tested system

[0186]

[0187] Table 8 Test Execution Results and Judgments

[0188]

[0189] Table 9 Vulnerability Summary

[0190]

[0191] / * Security Judgment Criteria Engine * / / / This code segment implements the core logic of the security judgment and reporting module, including vulnerability type definition, vulnerability record structure, various vulnerability judgment functions, and security impact level determination functions.

[0192] typedef enum { / / Defines the vulnerability type enumeration VulnType, which lists four types of security vulnerabilities that may exist in the AFDX end system and the result of determining whether there is a vulnerability.

[0193] VULN_NONE = 0, / / No vulnerability flag. A value of 0 indicates that the test case did not trigger any security vulnerabilities and the end system behavior is as expected (e.g., correctly discarding illegal frames).

[0194] VULN_VL_ISOLATION, / / VL isolation failure vulnerability flag, indicating that the end system failed to correctly implement the virtual link isolation mechanism and accepted and processed frames that did not belong to a valid VL of this end system.

[0195] / * VL isolation failed * /

[0196] VULN_REPLAY, / / Vulnerability flag for replay failure, indicating that the redundancy management (RM) module of the end system failed to detect the sequence number replay attack, and the replay frame was accepted as a normal frame.

[0197] / * Replay protection fails * /

[0198] VULN_DOS, / / Denial-of-service vulnerability flag, indicating that a sudden traffic attack caused the end system to discard frames from legitimate virtual links, affecting normal communication functions.

[0199] / * Deny service * /

[0200] VULN_PAYLOAD / / A vulnerability flag for payload processing, indicating that abnormally formatted payload data causes upper-layer applications to crash, output out of range, or time out in response.

[0201] / * Load handling error * /

[0202] } VulnType; / / The enumeration is now defined. The four types of vulnerabilities correspond to the four dangerous states D1 to D4 in the safe state machine. The decision function reports the type of vulnerability found by returning the corresponding enumeration value.

[0203] typedef struct { / / Defines a vulnerability record structure VulnRecord, which stores complete information about a confirmed vulnerability and is used to summarize and generate a vulnerability test report in DO-356A format.

[0204] int test_case_id; / / The test case number that triggered the vulnerability. It records which test frame caused the vulnerability to be exposed, supporting forward tracing from vulnerability to test case.

[0205] VulnType type; / / Fragility type, which takes the value of one of the following from the VulnType enumeration: VULN_VL_ISOLATION, VULN_REPLAY, VULN_DOS, or VULN_PAYLOAD.

[0206] int dal_level; / / Security impact level, expressed as the Design Assurance Level (DAL) of the affected virtual link bearer function: 0=DAL A (highest, flight critical), 1=DAL B, 2=DAL C, 3=DAL D, 4=DAL E (lowest).

[0207] / * 0=A, 1=B, 2=C, 3=D, 4=E * /

[0208] char description

[256] ; / / Vulnerability description string, which records the behavior of the vulnerability in human-readable text (e.g., "The end system accepted the illegal frame with VL ID=VL500 and forwarded it to the upper layer application").

[0209] char recommendation

[256] ; / / Repair suggestion string, a disposal suggestion generated based on the vulnerability type and impact level (e.g., "Must be repaired: Enable strong RM sequence number continuity check").

[0210] } VulnRecord; / / The structure is now defined. Each VulnRecord instance corresponds to one vulnerability record in the vulnerability test report. All records are sorted by impact level and output as a complete report.

[0211] VulnType judge_vl_isolation(TestResult *result) { / / Function definition: VL isolation failure judgment function, the input parameter result is a pointer to the response result structure of the backend system of the test execution, and the return value is the determined vulnerability type.

[0212] / * Judgment condition: The payload of an illegal VL ID frame is received by the upper-layer application * / / / The following comments explain the judgment logic of VL isolation failure: It is only considered vulnerable when an illegal VL ID frame is not only received by the end system but its payload data actually reaches the upper-layer application.

[0213] if (result->mutation_type == MUT_VL_ID && / / First condition: Confirm that the mutation type of this test case is VL ID field mutation (MUT_VL_ID), and ensure that this condition is only performed on VL ID mutation test cases.

[0214] result->frame_accepted && / / Second condition: The end system accepts the frame instead of discarding it, that is, the frame has passed the end system's frame header parsing and VL matching stage (this is an error for frames with invalid VL IDs).

[0215] result->payload_delivered_to_app) { / / The third condition: the frame's payload data is actually forwarded to the upper-layer application, indicating that the data of the illegal VL has polluted the application layer, and the VL isolation mechanism has completely failed.

[0216] return VULN_VL_ISOLATION; / / If all three conditions are met, it is determined to be a vulnerability due to VL isolation failure, and the VULN_VL_ISOLATION enumeration value is returned, corresponding to the D1 dangerous state in the safety state machine.

[0217] / / End of conditional block. If all three conditions are not met simultaneously, the VL isolation is not considered to have failed.

[0218] return VULN_NONE; / / Returns VULN_NONE if the condition is not met, indicating that the test case did not trigger the VL isolation failure vulnerability (the end system correctly discarded the illegal frame).

[0219] } / / After the function finishes execution, the return value is passed to the vulnerability recording module. If it is VULN_VL_ISOLATION, the corresponding VulnRecord record is created.

[0220] VulnType judge_replay(TestResult *result) { / / Function definition: Anti-replay failure judgment function, the input parameter result is the response result of the backend system of the test execution, and the return value is the vulnerability type.

[0221] / * Judgment condition: The replay sequence number frame is not detected by the RM and is forwarded normally * / / / The following comments explain the judgment logic of anti-replay failure: The replay frame bypasses the sequence number detection of the RM module and is treated as a normal frame by the end system.

[0222] if (result->mutation_type == MUT_SEQ_NUM && / / First condition: confirm that the mutation type of this test case is sequence number field mutation (MUT_SEQ_NUM), and limit the judgment scope to sequence number mutation test cases.

[0223] result->seq_anomaly_type == SEQ_REPLAY && / / Second judgment condition: Confirm that the specific type of the sequence number anomaly is replay (SEQ_REPLAY), that is, the frame used an old sequence number that has appeared before, which is different from skip frames and out-of-order frames.

[0224] !result->rm_alert_triggered && / / The third judgment condition: The redundancy management (RM) module of the end system did not trigger the sequence number abnormality alarm, indicating that the RM did not detect the sequence number abnormality of the replay frame.

[0225] result->frame_accepted) { / / Fourth condition: The replay frame is accepted and processed normally by the end system (not discarded), indicating that the attacker can successfully replay the old data frame.

[0226] return VULN_REPLAY; / / If all four conditions are met, it is determined to be a vulnerability to replay failure, and the VULN_REPLAY enumeration value is returned, corresponding to the D2 dangerous state in the safe state machine.

[0227] / / End of conditional block. If any condition is not met, the anti-replay failure is not considered.

[0228] return VULN_NONE; / / Returns VULN_NONE if the condition is not met, indicating that the end system's RM mechanism correctly detected and rejected the replay frame (or the use case is not a sequence number mutation of the replay type).

[0229] / / After the function finishes execution, the return value is passed to the vulnerability recording module for further processing.

[0230] VulnType judge_dos(TestResult *result, / / Function definition: Denial-of-service judgment function, the first parameter result is the end system response result.

[0231] double loss_threshold) { / / The second parameter loss_threshold is the preset threshold for the frame drop rate of a valid VL frame. If the frame drop rate exceeds this threshold, it is considered a denial-of-service vulnerability (e.g., setting it to 0.05 means a 5% frame drop rate).

[0232] / * Judgment condition: Sudden traffic causes the frame drop rate of legitimate VLs to exceed the threshold * / / / The following comments explain the denial-of-service judgment logic: Sudden traffic caused by timing variations causes frames of legitimate virtual links to be squeezed and dropped.

[0233] if (result->mutation_type == MUT_TIMING && / / First condition: confirm that the mutation type of this test case is frame interval temporal mutation (MUT_TIMING), and limit the judgment scope to burst traffic test cases.

[0234] result->legitimate_vl_loss_rate > loss_threshold) { / / Second judgment condition: The frame loss rate of the legitimate VL on the tested system exceeds the preset threshold, indicating that the burst traffic has affected the normal communication function.

[0235] return VULN_DOS; / / If both conditions are met, it is determined to be a denial-of-service vulnerability, and the VULN_DOS enumeration value is returned, corresponding to the D3 dangerous state in the security state machine.

[0236] / / End of conditional block. If the frame drop rate does not exceed the threshold, the end system's traffic shaping mechanism effectively defends against sudden attacks.

[0237] return VULN_NONE; / / Returns VULN_NONE if the condition is not met, indicating that legitimate VL communication on the end system was not significantly affected under this burst traffic level.

[0238] / / After the function finishes executing, the return value is passed to the vulnerability recording module.

[0239] / * Determine the security impact level * / / / The following function determines the security impact level of a vulnerability, calculating the final impact level based on the vulnerability type and the DAL level of the affected VL.

[0240] int get_impact_level(VulnType type, / / Function definition: The first parameter type is an enumeration value of the identified vulnerability type.)

[0241] int affected_vl_dal) { / / The second parameter affected_vl_dal is the design guarantee level (DAL) of the function carried by the virtual link affected by the vulnerability, 0=A, 1=B, 2=C, 3=D, 4=E.

[0242] if (type == VULN_REPLAY) { / / Determine if the vulnerability type is anti-replay failure. The security impact of anti-replay failure needs to be handled specially (one level lower than other vulnerability types).

[0243] / * Anti-replay failure: Impact level reduced by one level * / / / The reason for reducing the impact level of anti-replay failure by one level is that the impact of a single replay frame is usually lower than that of a persistent attack (such as denial of service), and the upper-layer application of the end system may have a certain tolerance for single frame anomalies.

[0244] return (affected_vl_dal < 4) ? affected_vl_dal + 1 / / If the DAL level number of the affected VL is less than 4 (i.e. not the lowest DAL E), the impact level is reduced by one level (the number is increased by 1), such as DALA(0) being reduced to DAL B(1).

[0245] : affected_vl_dal; / / If it is already the lowest DAL E (number 4), then it will not be lowered further, and the DAL E will remain unchanged to avoid the level number from exceeding the valid range.

[0246] / / End of conditional block; the impact level of replay failure has been downgraded.

[0247] return affected_vl_dal; / / For the three types of vulnerabilities—VL isolation failure, denial of service, and load processing anomaly—the security impact level is directly taken as the DAL level of the function carried by the affected VL, without adjustment.

[0248] / * For other types, directly take the DAL of VL * /

[0249] } / / After the function finishes executing, the impact level returned is used in the dal_level field of the VulnRecord structure to determine the level of handling recommendation for this vulnerability in the report (must be fixed / recommend to be fixed / risk accepted for review).

[0250] In some examples, such as Figure 4 As shown, using the same tested system (ES-2000) as the test object, this paper presents a comparison of the test efficiency of the state-guided mutation method and the random fuzzy testing method. The test configuration is shown in Table 10, and the test results are compared in Table 11.

[0251] Table 10 Test Configuration

[0252]

[0253] Table 11 Comparison of Test Results

[0254]

[0255] Key Differences Analysis: The state-guided mutation method discovered 12 vulnerabilities in 287 test cases, requiring an average of only 24 test cases per vulnerability. Syntax-based random fuzzing discovered only 5 vulnerabilities in 10,000 test cases because most frames generated by random mutation were correctly discarded during the VL matching phase (since randomly generated VL IDs are unlikely to be in the configuration table), with only a very small number of frames touching deeper RM verification and BAG check logic. Pure random fuzzing performed even worse, discovering only 2 vulnerabilities in 50,000 test cases, because the vast majority of frames generated by random byte mutation were discarded during the frame header parsing phase. The advantage of the state-guided method is that each test case is constructed for a specific transition path in the secure state machine, enabling it to penetrate pre-check phases such as frame header parsing and VL matching to reach deeper security mechanisms.

[0256] In summary, this invention provides a security testing method for airborne AFDX networks. By modeling the AFDX protocol stack as a security state machine, and adding security-related states and malicious input migrations to the normal protocol state machine, a state-guided directed mutation test case generation algorithm is proposed. Differential mutation rules are applied to different fields of AFDX frames to drive the tested system to a dangerous state. A security judgment criterion engine automatically determines the vulnerability type and security impact level, thereby generating a vulnerability test report conforming to a preset format (e.g., DO-356A format). Therefore, this method performs multi-dimensional field-level differential mutations targeting the virtual links, redundancy management, bandwidth allocation intervals, and payload semantics of the AFDX protocol characteristics, generating high-value test cases and prioritizing them by path length and coverage, achieving comprehensive coverage of AFDX-specific vulnerability categories. The microsecond-level high-precision physical injection is performed through an FPGA frame real-time injection engine, eliminating the physical latency and jitter introduced by traditional network protocol stacks and meeting the timing mutation testing requirements related to bandwidth allocation intervals. Ultimately, by capturing the system response and matching it with multi-dimensional judgment criteria, vulnerabilities such as virtual link isolation failure, replay failure, denial-of-service, and payload processing anomalies can be automatically identified and classified. Combined with aviation safety standards, the security impact level of affected virtual links is dynamically determined, and a compliance vulnerability report conforming to DO-356A is automatically generated. This significantly reduces the cost of manual analysis and improves the scientific rigor and airworthiness compliance of the assessment conclusions. Therefore, this method can understand the protocol semantics and behavioral constraints of AFDX, systematically detect security vulnerabilities in VL isolation, RM integrity, BAG flow control, and payload processing, and is equipped with a dedicated testing device supporting precise timing injection of AFDX frames.

[0257] like Figure 5 As shown, in an exemplary embodiment of the present invention, a security testing system for airborne AFDX networks is provided, the system comprising:

[0258] The security state machine modeling module is used to obtain the AFDX protocol specification and construct a security state machine based on the protocol stack in the AFDX specification. It also adds security-related state nodes and malicious input transition edges to the security state machine. Security-related states include normal states, alarm states, and dangerous states. Malicious input transition edges describe the state transition behavior of the AFDX end system when it receives illegal frames. Illegal frames include illegal virtual link identifier frames, replay sequence number frames, burst frames that violate bandwidth allocation table constraints, and abnormally formatted payload frames. Specifically, the security state machine modeling module establishes a security state machine for the receiving end of the AFDX end system. Unlike functional protocol state machines that only describe the normal communication process, the security state machine additionally models the behavior of the end system when receiving various types of illegal frames. The module first extracts the normal protocol state machine (reception and parsing of legal frames, VL matching, RM sequence number verification, BAG compliance check, and payload forwarding process). Then, it adds security-related states to each processing stage: an illegal VL alarm state when the VL ID is not in the configuration table, an abnormal sequence number alarm state when the sequence number is not consecutive, and a traffic over-limit alarm state when the frame interval violates BAG constraints. The corresponding dangerous states are defined as: VL isolation failure, anti-replay failure, and denial of service when the end system fails to properly handle alarms (e.g., accepting illegal VL frames, failing to detect replay frames, or legal frames being discarded due to burst traffic). Finally, the module performs integrity verification on the security state machine to ensure that all dangerous states are reachable from the initial state (i.e., there exists a constructible input sequence).

[0259] The State-Guided Mutation Testing Module performs a reverse breadth-first search within the safe state machine, starting from the initial state and ending at each dangerous state, to find the shortest migration path from the initial state to the dangerous state in the AFDX end system. Each migration edge on the path corresponds to an input frame. Furthermore, it generates test cases by applying differentiated mutation rules to different fields of the AFDX input frames. Specifically, as the core module, unlike the random mutation in general fuzz testing, this module performs targeted testing on each dangerous state within the safe state machine. The module first performs a reverse breadth-first search within the safe state machine, starting from the initial state and ending at each dangerous state, to find the shortest migration path to that dangerous state. Each migration edge on the path corresponds to a required input frame feature. Then, test frames are constructed according to the differential variation rules of each field: the VL ID field selects a valid Ethernet frame format value outside the configuration table to test VL isolation; the sequence number field constructs replay frames, out-of-order frames, and skip frames to test the RM mechanism; the payload field constructs boundary values ​​and outliers based on the upper-layer application protocol format to test payload processing security; the frame interval is controlled below the BAG constraint to test the traffic shaping mechanism. After the test cases are sorted by path length (shortest paths are tested first) and coverage (prioritizing coverage of untested dangerous states), they are injected into the system under test with microsecond precision through the FPGA frame injection engine.

[0260] The security assessment and reporting module injects generated test cases into the network interfaces of the AFDX end system according to the timing requirements, captures the response behavior of the AFDX end system, and matches the response behavior with predefined vulnerability assessment rules through a security assessment criterion engine. Based on the design assurance level of the functions carried by the affected virtual links, it determines the security impact level of the successfully matched vulnerabilities and generates a vulnerability test report conforming to a preset format. Specifically, the security assessment and reporting module automatically evaluates the test results. The module captures the response behavior of the end system under test to each test frame (whether it drops the frame, forwards it to the upper layer, triggers an alarm, or affects the frame processing of other VLs), and matches it with predefined assessment criteria: the end system accepting illegal VL frames is considered a VL isolation failure; failure to detect replay frames is considered a lack of anti-replay mechanism; sudden traffic causing the loss of legitimate frames is considered a denial of service; and abnormal load causing application crashes or out-of-range output is considered a load processing vulnerability. The security impact level of each discovered vulnerability is determined according to the DAL level of the functions carried by the affected VL, and a vulnerability test report conforming to the DO-356A format is generated.

[0261] In some exemplary embodiments, the security testing system for airborne AFDX networks may further include: an AFDX interface module, which contains an AFDX physical interface supporting dual redundant networks for connecting network A and network B of the AFDX end system, and provides frame injection and frame listening functions.

[0262] In some exemplary embodiments, the security testing system for airborne AFDX networks may further include: a real-time frame generation and injection module, used to generate AFDX input frames in real time according to the frame content and timing parameters specified in the test cases; and a response capture and analysis module, used to capture the network response frames and interface behaviors of the AFDX end system after receiving the test frames, record the frame timestamps and content, and transmit the capture results to the host computer.

[0263] In an exemplary embodiment, the security testing system for airborne AFDX networks may further include: host computer control and analysis software, comprising a security state machine editor, a mutation policy configuration interface, a test execution control module, and a vulnerability report generation module, to realize a complete testing process from security state machine modeling to vulnerability report output.

[0264] It should be noted that the security testing system for airborne AFDX networks provided in the above embodiments and the security testing method for airborne AFDX networks provided in the above embodiments belong to the same concept. The specific methods of operation of each module and unit have been described in detail in the method embodiments and will not be repeated here. In practical applications, the security testing system for airborne AFDX networks provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the system can be divided into different functional modules to complete all or part of the functions described above. No limitation is imposed here. Therefore, the present invention effectively overcomes the various shortcomings of the prior art and has high industrial application value.

[0265] In summary, this invention provides a security testing system for airborne AFDX networks. By modeling the AFDX protocol stack as a security state machine, and adding security-related states and malicious input migrations to the normal protocol state machine, a state-guided directed mutation test case generation algorithm is proposed. Differential mutation rules are applied to different fields of AFDX frames to drive the tested system to a dangerous state. A security judgment criterion engine automatically determines the vulnerability type and security impact level, thereby generating vulnerability test reports conforming to a preset format (e.g., DO-356A format). Therefore, this method performs multi-dimensional field-level differential mutations targeting the virtual links, redundancy management, bandwidth allocation intervals, and payload semantics of the AFDX protocol characteristics, generating high-value test cases and prioritizing them by path length and coverage, achieving comprehensive coverage of AFDX-specific vulnerability categories. The FPGA frame real-time injection engine performs microsecond-level high-precision physical injection, eliminating the physical latency and jitter introduced by traditional network protocol stacks, and meeting the timing mutation testing requirements related to bandwidth allocation intervals. Ultimately, by capturing system responses and matching them with multi-dimensional judgment criteria, the system can automatically identify and classify vulnerabilities such as virtual link isolation failure, replay failure, denial-of-service, and payload processing anomalies. It also dynamically determines the security impact level of affected virtual links based on aviation safety standards, automatically generating a compliance vulnerability report compliant with DO-356A standards. This significantly reduces the cost of manual analysis and improves the scientific rigor and airworthiness compliance of the assessment conclusions. Therefore, this system can understand the protocol semantics and behavioral constraints of AFDX, systematically detect security vulnerabilities in VL isolation, RM integrity, BAG flow control, and payload processing, and is equipped with a dedicated testing device that supports precise timing injection of AFDX frames.

[0266] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the invention. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the claims of the present invention.

Claims

1. A security testing method for airborne AFDX networks, characterized in that, The method includes the following steps: The AFDX protocol specification is obtained, and a security state machine is constructed based on the protocol stack in the AFDX protocol specification. Security-related state nodes and malicious input migration edges are added to the security state machine. The security-related states include normal state, alarm state, and dangerous state. The malicious input migration edges are used to describe the state transition behavior of the AFDX end system when it receives a violation frame. The violation frame includes illegal virtual link identifier frames, replay sequence number frames, burst frames that violate bandwidth allocation table constraints, and abnormal format payload frames. In the safety state machine, a reverse breadth-first search is performed with each dangerous state as the endpoint and the initial state as the starting point to find the shortest migration path for the AFDX end system from the initial state to the dangerous state. Each migration edge on the migration path corresponds to an input frame. Furthermore, test cases are generated by applying differential mutation rules to different fields of the AFDX input frame. The generated test cases are injected into the network interface of the AFDX end system according to the timing requirements to capture the response behavior of the AFDX end system; and the response behavior is matched with the predefined vulnerability judgment rules through the security judgment criterion engine, and the security impact level of the successfully matched vulnerability is determined according to the design guarantee level of the function carried by the affected virtual link, and a vulnerability test report in a preset format is generated.

2. The security testing method for airborne AFDX networks according to claim 1, characterized in that, The construction process of the secure state machine includes: A security state machine is established for the receiver of each AFDX end system. The initial state of the security state machine is normal reception, and it remains in the normal state when a legitimate frame is received. The legitimate frame includes frames identified by the virtual link in the configuration table, frames with consecutive sequence numbers, and frames whose frame intervals conform to the constraints of the bandwidth allocation table. Define alarm state transitions, including: transitioning to illegal virtual link alarm state when a frame with a virtual link identifier not in the configuration table is received; transitioning to sequence number abnormal alarm state when a frame with a non-contiguous sequence number is received; and transitioning to traffic over-limit alarm state when a frame with a frame interval less than the minimum value in the bandwidth allocation table is received. Define dangerous state transitions, including: if the AFDX end system receives and processes the corresponding frame under the illegal virtual link alarm state, it will transition to the virtual link isolation failure dangerous state; if it receives a replay frame under the sequence number abnormal alarm state, it will transition to the anti-replay failure dangerous state; if it continuously receives excessive traffic causing the frames of the legitimate virtual link to be dropped, it will transition to the denial-of-service dangerous state.

3. The security testing method for airborne AFDX networks according to claim 1, characterized in that, The differential variation rules include virtual link identifier field variation, sequence number field variation, payload field variation, and frame interval variation; The virtual link identifier field variation is used to select a virtual link identifier value from outside the virtual link configuration table of the AFDX end system, construct a cross-virtual link injection frame, and keep other fields of the frame valid, in order to test whether the AFDX end system filters illegal frames only based on the virtual link identifier; among them, other fields include MAC address and Ethernet type; The sequence number field is mutated to record the sequence number sequence in normal communication of the AFDX end system, and to construct replay frames, out-of-order frames and skip frames to test the redundancy management mechanism of the AFDX end system to detect various sequence number anomalies. The payload field variation is used to parse the data format constraints of the application protocol in the AFDX frame payload. It injects boundary values ​​and out-of-range values ​​into the numerical field, undefined enumerated values ​​into the enumerated field, and values ​​that do not match the actual payload into the length field. Among them, the boundary values ​​include the maximum value, minimum value, and zero value. Frame interval variation is used to construct burst traffic sequences that violate bandwidth allocation table constraints. More frames than the configured allowable number are sent within the bandwidth allocation table period, gradually increasing from single-frame bursts to continuous bursts, in order to test the traffic shaping mechanism of the AFDX end system and its ability to protect legitimate virtual link frames under burst traffic.

4. The security testing method for airborne AFDX networks according to claim 3, characterized in that, The replay frame represents a frame using a sequence number that has already appeared, the out-of-order frame represents a frame using a non-incrementing sequence number, and the skip frame represents a frame using a sequence number greater than the current value.

5. The security testing method for airborne AFDX networks according to claim 1, characterized in that, The method further includes: When searching for the shortest migration path, for dangerous states requiring multiple migration steps to reach, the input frame sequence is constructed sequentially according to the migration edges on the migration path. The construction of each input frame is based on the triggering conditions of the migration edges and the current state of the AFDX end system; and, In cases where multiple migration paths lead to the same dangerous state, the migration paths are sorted from shortest to longest. Test cases are generated first for the shortest migration path, and then test cases for the other migration paths are generated.

6. The security testing method for airborne AFDX networks according to claim 1, characterized in that, The security determination criteria include: virtual link isolation failure determination, anti-replay failure determination, denial-of-service determination, and payload processing anomaly determination. The virtual link isolation failure determination is used to determine the vulnerability of virtual link isolation when the upper layer application of the AFDX end system receives payload data of illegal virtual link identification frame. The security impact level is the highest design guarantee level among all legal virtual links on the AFDX end system. The anti-replay failure determination is used to determine the vulnerability of the anti-replay mechanism when the AFDX end system fails to detect replay frames. Denial-of-service determination is used to identify a vulnerability as a denial-of-service vulnerability when a sudden surge in traffic causes the AFDX end system to drop frames from legitimate virtual links within a bandwidth allocation table period and the frame drop rate exceeds a preset threshold. The payload processing anomaly determination is used to determine payload processing vulnerability when semantically mutated frames cause abnormal behavior in the upper-layer application of the AFDX end system. The security impact level is taken as the design guarantee level of the application function. Abnormal behavior includes crashes, out-of-range output values, or response timeouts.

7. The security testing method for airborne AFDX networks according to claim 1, characterized in that, The rules for generating vulnerability test reports include: For each discovered vulnerability, record the test case number that triggered the vulnerability, the variant field type, the variant value, the end system response behavior, and the judgment result; The security impact level is determined based on the design assurance level and vulnerability type of the functions carried by the affected virtual links: the impact level of virtual link isolation failure and denial-of-service vulnerability is directly taken as the DAL level of the affected function, and the impact level of replay failure vulnerability is reduced by one level based on the DAL level of the affected function. For each vulnerability, a remediation recommendation is generated according to its impact level: vulnerabilities affected by DAL A and DAL B are marked as requiring remediation, vulnerabilities affected by DAL C are marked as requiring remediation, and vulnerabilities affected by DAL D and DAL E are marked as subject to risk review.

8. A security testing system for airborne AFDX networks, characterized in that, The system includes: The security state machine modeling module is used to obtain the AFDX protocol specification, construct a security state machine based on the protocol stack in the AFDX protocol specification, and add security-related state nodes and malicious input migration edges to the security state machine. The security-related states include normal state, alarm state, and dangerous state. The malicious input migration edges are used to describe the state transition behavior of the AFDX end system when it receives a violation frame. The violation frame includes illegal virtual link identifier frames, replay sequence number frames, burst frames that violate bandwidth allocation table constraints, and abnormal format payload frames. The state-guided mutation test module is used to perform a reverse breadth-first search in the safety state machine with each dangerous state as the endpoint and the initial state as the starting point to find the shortest migration path for the AFDX end system from the initial state to the dangerous state. Each migration edge on the migration path corresponds to an input frame. The module also generates test cases by applying differential mutation rules to different fields of the AFDX input frame. The security assessment and reporting module is used to inject the generated test cases into the network interface of the AFDX end system according to the timing requirements, capture the response behavior of the AFDX end system, and match the response behavior with the predefined vulnerability assessment rules through the security assessment criterion engine. Based on the design assurance level of the function carried by the affected virtual link, the module determines the security impact level of the successfully matched vulnerability and generates a vulnerability test report in a preset format.

9. The security testing system for airborne AFDX networks according to claim 8, characterized in that, The system also includes an AFDX interface module, which contains an AFDX physical interface that supports dual redundant networks, for connecting network A and network B of the AFDX end system, and provides frame injection and frame listening functions.

10. The security testing system for airborne AFDX networks according to claim 8, characterized in that, The system also includes a real-time frame generation and injection module, which is used to generate AFDX input frames in real time according to the frame content and timing parameters specified in the test case. The response capture and analysis module is used to capture the network response frames and interface behavior of the AFDX end system after receiving the test frame, record the frame timestamp and content, and transmit the capture results to the host computer.

Images