Method for controlling communication between a high-security critical component and a low-security non-critical component of a computer and controller for implementing such a method
A method and FPGA-based controller manage data flow between critical and non-critical computer parts, addressing the bulkiness and security gaps in existing systems by performing integrity checks and secure key validation, thereby enhancing aircraft safety and cybersecurity.
Patent Information
- Application Number
- PCT/FR2025/050583
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-06-26
- Filing Date
- 2025-06-25
- Publication Date
- 2026-01-02
AI Technical Summary
Existing methods for controlling communication between critical and non-critical computer components in the aeronautical field are bulky and do not adequately protect critical systems from cybersecurity attacks, particularly in aircraft control devices where flight safety is paramount.
A method and controller are introduced to manage data flow between high-safety critical and low-safety non-critical parts within a computer, utilizing a programmable circuit (FPGA) to perform integrity checks and secure key validation, ensuring only authorized data flow between these parts.
The solution effectively protects critical components from potential attacks while minimizing system size, ensuring secure and efficient communication control within a computer, thus enhancing aircraft safety and cybersecurity.
Smart Images

Figure FR2025050583_02012026_PF_FP_ABST
Abstract
Description
[0001] DESCRIPTION
[0002] TITLE OF THE INVENTION: Method for controlling communication between a high-security critical part and a low-security non-critical part of a computer and controller for implementing such a method
[0003] TECHNICAL FIELD
[0004] The invention relates to a method of communication between equipment in different security zones. It also relates to a device configured to implement such a method.
[0005] STATE OF THE ART
[0006] In the aeronautical field, computers carrying critical and non-critical functions coexist and must be able to communicate with each other.
[0007] However, it is necessary to ensure that the computer carrying critical functions cannot be corrupted by attacks or erratic operations originating from the non-critical computer.
[0008] In the aeronautical field where critical computers (for example DAL - Design Assurance Level A or B according to the classification indicating a level of reliability required for electronic systems on board aircraft) include non-critical functions (DAL D or E) this guarantee must be very strong or even absolute, especially with regard to cybersecurity attacks where the protection of critical functions related to flight safety is paramount.
[0009] This is particularly necessary for critical computers linking aircraft control devices which must offer a very high level of safety, especially during flight phases.
[0010] Document FR3015830 discloses a device for controlling communication between two pieces of equipment located in different security zones. Such a device is unsatisfactory because it requires implementation in an external enclosure and a disconnect between the two pieces of equipment to be separated. This leads to a bulky solution. DESCRIPTION OF THE INVENTION
[0011] The invention proposes a solution for controlling and therefore cutting off communications between different security zones within the same computer.
[0012] To this end, the invention proposes, according to a first aspect, a method of communication between a high-safety critical part of a computer and a low-safety non-critical part of the computer, the method comprising the following steps, implemented within a controller interposed in the computer between the critical part and the non-critical part, the computer being configured to open or close a data flow on a critical link between the critical part and the non-critical part:
[0013] - receipt of a request to open the data flow from the critical part in order to allow a data flow between the critical part and the non-critical part;
[0014] - self-checking the integrity of the controller; and whether the controller is intact;
[0015] - opening the data flow on the critical link;
[0016] - receipt of a request to close the data flow on the critical link from the critical part;
[0017] - closing the data flow.
[0018] The invention is advantageously complemented by the following features, taken alone or in any technically possible combination thereof.
[0019] The request to open a flow and / or the request to close a flow includes a key, the process includes a validation of the request to open and / or close a flow, the key preferably being double.
[0020] The validation of the request to open and / or close the flow includes a comparison of the received key with a local key stored in a memory of the controller; the request to open and / or close the flow is validated if the local key is identical to the received key.
[0021] If the controller is not functioning correctly, the data flow on the critical link remains closed.
[0022] If the controller is not healthy, the process includes a step of sending an alert message to the critical component. The controller's self-check for integrity includes calculating a fingerprint from a controller configuration file stored at controller initialization and comparing the calculated fingerprint with a test fingerprint stored in the controller's memory.
[0023] The fingerprint is a hash function of the controller's configuration file; the controller's self-checking of integrity includes a comparison of the calculated hash function to a hash function of the same configuration file calculated and stored in the controller's memory.
[0024] The hash function is a non-reverse SHA-256 hash function.
[0025] The controller is a programmable circuit, preferably an FPGA.
[0026] The non-critical part is a computer qualified DAL D or E and in which the critical part is a computer qualified DAL A, DAL B or DAL C.
[0027] The invention proposes, according to a second aspect, a controller for communication between a critical part of a computer and a non-critical part of the computer, the controller comprising at least one processor configured to implement a method according to the first aspect of the invention.
[0028] The method allows the controller to either interrupt or allow the data flow from the critical part to the non-critical part. The invention therefore makes it possible to protect the critical part from potential attacks originating from the non-critical part.
[0029] Advantageously, the controller thus implements a secure communication process between computer components with different security levels, ensuring the controller's own integrity by efficiently and securely controlling the opening and closing of the data flow from the non-critical component. The controller's integration into the computer facilitates its integration within the aircraft, thereby minimizing its overall size.
[0030] The critical part, deemed healthy because it is properly protected, then decides whether to allow data flow from the non-critical part, in accordance with its environment. The critical part is the sole master of the communication link between the critical and non-critical parts. Only the critical part can initiate a transaction on this communication link.
[0031] Advantageously, the controller is activated and deactivated securely via a preferably double-key writing sequence. If an incorrect key is entered or the sequence is incomplete, the controller remains secure (no communication is possible from the non-critical part to the critical part). Since the countermeasure implemented in the controller relies on signals provided by the critical part, the invention ensures the integrity of the critical part to guarantee its operation.
[0032] This is particularly advantageous in a critical multi-DAL system, where an isolation function independent of other systems is required.
[0033] PRESENTATION OF THE FIGURES
[0034] Other features, purposes and advantages of the invention will become apparent from the following description, which is purely illustrative and not limiting, and which should be read in conjunction with the accompanying drawings on which:
[0035] - Figure 1 illustrates a computer, according to one embodiment, comprising two parts of different security levels between which a controller is interposed to control communications between the two parts;
[0036] - Figure 2 illustrates a communication control method implemented in a control unit according to one embodiment.
[0037] Across all figures, similar elements bear identical references.
[0038] DETAILED DESCRIPTION
[0039] Figure 1 illustrates a computer 1 comprising two parts 11, 12. A part 11 of high safety level or critical part and a part 12 of low safety level or non-critical part. It is specified here that there is indeed only one computer 1.
[0040] The security level refers to a set of rules and operating constraints imposed on the party to ensure that only authorized data flows can pass through the party in question.
[0041] A computer is understood to be a component comprising several processors or several microcontrollers enabling the execution of instructions and including one or more volatile or non-volatile memories.
[0042] Critical or non-critical parts of the computer are defined as independent computer components designed to operate with different levels of safety, these components being allocated within the computer. Preferably, and according to levels of operational safety, the components are qualified according to the DAL EUROCAE ED-12 (Europe) or RTCA DO-178C standard, with several levels of criticality (from most critical to least critical):
[0043] - DAL A: This is the strictest level of criticality. A failure of a DAL A component can have catastrophic consequences for aircraft safety;
[0044] - DAL B: a failure of a DAL B part can lead to serious but not necessarily catastrophic consequences for aircraft safety;
[0045] - DAL C: a failure of a DAL C part can have consequences for aircraft safety, but these consequences are limited;
[0046] - DAL D: a failure of a DAL D part is not likely to have a significant impact on aircraft safety;
[0047] - DAL E: this level is used for functions that do not contribute to aircraft safety.
[0048] These DAL criticality levels allow for the assessment of the potential impact of failures in avionics systems. DAL levels A, B, and C are the most commonly used in safety-critical systems such as piloting, navigation, and flight control systems.
[0049] The critical part is for example qualified DAL A or B or C and the non-critical part is for example qualified DAL D (or E), the computer thus being a multi-DAL computer to operate with systems where different levels of safety are required.
[0050] Between the critical part 11 and the non-critical part 12 is inserted a controller 2 configured to control communications between the critical part 11 and the non-critical part 12. In particular, the controller 2 allows to cut off or not a flow of data coming from the non-critical part to the critical part.
[0051] Advantageously, the data flow passes through a non-critical link 21 for data coming from the critical part to the non-critical part, and through a critical link 22 for data coming from the non-critical part to the critical part. A communication link is, for example, defined on a communication bus connecting the critical part 11 to the non-critical part 12.
[0052] It should be noted that the non-critical link 21 always allows a data flow to pass through, while the critical link 22 is managed by the controller 2 to close the data flow or not according to a communication process between a high-safety critical part 11 of a computer 1 and a low-safety non-critical part 12 of the computer 1 described in relation to Figure 2 (see below).
[0053] Controller 2 is preferably a programmable circuit such as an FPGA (Field Gate Programmable Array). Using an FPGA to implement the control process allows for an extremely high level of cybersecurity (SAL 3, for Security Assurance Level - 3 according to Anglo-Saxon terminology).
[0054] It is specified that the level of security assurance is defined according to the EUROCAE ED-203A / RTCA DO-356A standard and offers four levels ranging from SALO (the lowest) to SAL3 (the highest).
[0055] SALO: No protective effect. This level is limited to the initial assessment of protection needs and applies to systems and articles to which no higher SAL is assigned.
[0056] SAL1: Minimum security assurance for security measures: Suitable for additional protection or reinforcement / resilience. It provides a minimum level of confidence in the security measures implemented.
[0057] SAL2: Essential confidence in the secure development and operation of security measures: This level ensures that security measures are developed and operated securely, providing essential confidence in their effectiveness.
[0058] SAL3: Enhanced confidence in the secure development and operation of security measures. This level provides enhanced confidence in the secure development and operation of security measures, thus ensuring more rigorous protection against threats.
[0059] These SAL levels allow for the categorization and differentiation of safety requirements based on the importance and criticality of avionics systems, thus ensuring that appropriate safety measures are applied according to specific needs.
[0060] The computer 1 is preferably equivalent to two MCUs (379 mm x 436 mm x 60.80 mm). The controller 2 is also small and is a component of the computer, measuring 30 mm x 30 mm. As shown in Figure 2, at startup (step EO) of controller 2, it initializes and, by default, closes the data flow between the non-critical part 12 and the critical part 11 (step E1). The critical link 22 is then severed.
[0061] Furthermore, at the startup (EO stage) of controller 2, during its initialization, a controller integrity calculation is performed by a module within that controller. This calculation includes calculating a hash of a configuration file, preferably binary, loaded during controller 2's initialization, and comparing the resulting hash to a test hash that is previously loaded into non-volatile memory of controller 2 during its factory loading. The hash is, for example, a hash function (e.g., a non-inverse SHA-256 hash function) of the configuration file. Such a configuration file contains all the instructions for controller 1 to implement the process described herein.
[0062] If the calculated footprint is not identical to the test footprint, calculator 2 will not start.
[0063] When the controller is an FPGA, for example, it calculates a hash function (e.g., a non-inverse SHA-256 hash function) from the FPGA configuration file (bitstream) loaded during FPGA initialization. The calculated hash function is then compared to the hash function of the configuration file stored in dedicated non-volatile memory within the FPGA during factory configuration. Specifically, the hash function is calculated by a dedicated FPGA IP address.
[0064] Next, controller 2 is waiting for a request to open the data flow (step E2) from critical part 1 1.
[0065] A request to open the data stream on the critical link 22 is sent from the critical part 11 to the controller 2 (step E3). This open request is, for example, a write sequence (i.e., a message sent by the critical part 11 and read by the controller 2) with a dual key. This key received by the controller 2 is compared to a dual-key sequence 13 stored in the controller's memory (step E4). The key size depends on the system and the desired security level. The higher the security level, the larger the key size. For example, for SALO security level, a key with a minimum length of 8 bits is required, while for SAL3 security level, a key with a minimum length of 512 bits is more suitable. If the comparison shows that the received key is identical bit by bit to the stored key, then controller 2 validates the request to open the data stream (step E5).
[0066] An integrity check of controller 2 is then performed (step E6) by carrying out an integrity calculation (step E7). This calculation is similar to the one performed at the startup of controller 2 described above. If the calculated fingerprint is identical to the test fingerprint, then an integrity alert is raised and manifested by sending an integrity flag set to 0; otherwise, the integrity flag is set to 1 (step E8).
[0067] When the integrity flag is set to 1, the controller / FPGA sends an alert message to the critical part (step E9). Critical part 11 then receives this alert message (step E10). Upon receiving this alert, critical part 11 can decide to apply sanctions (step E15) which vary depending on its safety and cybersecurity level. For example, if the aircraft is in flight or on the ground, to ensure safety and cybersecurity, the data flow remains closed (returning to step E1). However, other possible sanctions may be applied depending on the aircraft's safety and cybersecurity level and situation.
[0068] When the integrity flag is set to 0 then the controller / FPGA commands the opening of the data flow (step E11) to allow a data flow from the non-critical part 12 to the critical part 11 on the critical link 22.
[0069] Controller 2 then awaits a request to close the data stream (step E12). When it receives a request to close the data stream (step E13) from the critical part 11, it terminates the process, which resets by closing the data stream and returning to step E1. As with the opening request, the closing request consists of the transmission (step E13) of a double-key write sequence. This key received by controller 2 is compared to a double-key sequence 14 stored in the controller's memory (step E14).
Claims
DEMANDS 1. Method for communication between a critical part (11) of high safety of a computer (1) and a non-critical part (12) of low safety of the computer (1), the method comprising the following steps, implemented within a controller (2) interposed in the computer (1) between the critical part (11) and the non-critical part (12), the computer (2) being configured to open or close a data flow on a critical link (22) between the critical part (11) and the non-critical part (12): - receipt (E2) of a request to open the data flow (E3) from the critical part (11) so as to allow a data flow between the critical part and the non-critical part; - self-check (E6) of the controller's integrity; and whether the controller is intact; - opening (E11) of the data flow on the critical link (21); - receipt (E12) of a request to close the data flow (E13) on the critical link (21) from the critical part (11); - closing (E1) of the data flow.
2. A method according to claim 1, wherein the request (E3) to open a flow and / or the request (E13) to close a flow includes a key, the method comprising a validation (E2, E12) of the request to open and / or close a flow, the key preferably being double.
3. Method according to claim 2, wherein the validation (E2, E12) of the request to open and / or close the flow includes a comparison (E4, E14) of the received key with a local key stored in a memory of the controller (2); the request to open and / or close the flow being validated if the local key is identical to the received key.
4. A method according to any one of the preceding claims, wherein if the controller (2) is not intact, the data flow on the critical link remains closed (E1).
5. A method according to any one of the preceding claims, wherein if the controller (2) is not intact, the method includes a step of emitting (E9) an alert message to the critical part (11).
6. A method according to any one of the preceding claims, wherein the self-check (E6) of the integrity of the controller (2) comprises a calculation (E7) of a fingerprint from a configuration file of the controller (2) stored at the initialization of the controller (2) and a comparison of the calculated fingerprint with a test fingerprint stored in a memory of the controller (2).
7. Method according to claim 6, wherein the fingerprint is a hash function of the controller configuration file (2), the controller integrity self-check comprising a comparison of the calculated hash function to a hash function of the same configuration file calculated and stored in a memory of the controller.
8. Method according to claim 7, wherein the hash function is a non-reverse SHA-256 hash function.
9. A method according to any one of the preceding claims, wherein the controller (2) is a programmable circuit, preferably an FPGA.
10. A method according to any one of the preceding claims, wherein the non-critical part (12) is a DAL D or E qualified computer and wherein the critical part (11) is a DAL A, DAL B or DAL C qualified computer.
11. Controller (2) of a communication between a critical part (11) of a computer (1) and a non-critical part (12) of the computer (1), the controller (2) comprising at least one processor configured to implement a method according to one of the preceding claims.
Citation Information
Patent Citations
Device for interconnecting communication networks with controlled security
FR3015830A1
System and method for information sharing between non-secure devices
US20100192217A1
Configurable cross-domain information assurance
US20170098094A1
Multi-level security domain separation using soft-core processor embedded in an FPGA
WO2016118224A1