Onboard network security gateway for connecting low and high trust domains of an avionics IT infrastructure.

Abstract

An onboard network security gateway for connecting low and high trust domains of an avionics IT infrastructure. This gateway, which connects a low trust domain (12) and a high trust domain (13) of an avionics IT infrastructure, offers a range of security functions, each function being performed by a data processing node.This gateway comprises, connected in series along a filtering chain for a data stream received from the low-trust domain: a firewall data processing node (4); a protocol break data processing node (5); a master data processing node (1); and a reverse protocol break data processing node (6). The gateway further comprises a security data processing node (2) connected to each of the data processing nodes in the filtering chain, with the different data processing nodes being physically segregated. See Figure 1 for abbreviations.

Description

Title of the invention: On-board network security gateway on board an aircraft for connecting low and high trust domains of an avionics IT infrastructure.

[0001] The present invention relates to the field of network security gateways intended to be installed on board civil or military aircraft.

[0002] A network security gateway allows an interconnection between two IT domains which are characterized by different levels of criticality, in particular between a low-trust domain and a domain critical to the safety (concept of "safety" in English) of the aircraft, such as for example the aircraft control domain - ACD ("Aircraft Control Domain").

[0003] This interconnection can be permanent, for example in the case of two aircraft networks used during a flight phase, or temporary, for example in the case of maintenance equipment connected to the aircraft during a ground maintenance phase.

[0004] The gateway makes it possible to protect the domain of higher criticality by filtering the data flows coming from the domain of lower criticality, by rejecting the data flows which are not compatible with the highest level of criticality, in particular the data flows corresponding to malicious computer attacks.

[0005] Such a gateway must be developed with the highest level of development for security (level “SAL 3” in the reference defined by the ED-203A standard) while ensuring good cyber-security properties, in particular the impossibility for an attacker to bypass the filtering functions implemented by the gateway.

[0006] However, compliance with such development requirements and verification to ensure the level of security actually provided constitute major difficulties.

[0007] The aim of the present invention is to propose a gateway architecture making it possible to address these problems.

[0008] For this purpose, the invention relates to a network security gateway intended to be installed on board an aircraft to connect a low trust domain and a high trust domain of an avionics IT infrastructure, the gateway offering a plurality of security functions, each function being performed by a data processing node, the gateway comprising, connected in series along a filtering chain of a data flow received from the low trust domain: a firewall data processing node; a data processing node; protocol break data; a master data processing node; and a reverse protocol break data processing node, the gateway further comprising a service node connected to each of the data processing nodes in the filtering chain, the different data processing nodes being physically segregated.

[0009] According to particular embodiments, the gateway comprises one or more of the following characteristics, taken individually or in all technically possible combinations:

[0010] - the nodes of the filter chain are connected by bidirectional links , preferably in Ethernet format, more preferably in 1 Gbit / s Ethernet format, having a bandwidth greater than that of the connections allowing the gateway to be connected to the high and low trust domains.

[0011] - the service node is connected to the plurality of nodes of the filter chain by one-way links, preferably in serial format, more preferably in synchronized serial format.

[0012] - the gateway constitutes an Ethernet and / or ARINC 429 and / or ARINC 664 interface, with the high trust domain and an Ethernet and / or ARINC 429 and / or ARINC 664 interface with the low trust domain.

[0013] - a firewall data processing node is connected to the domain of low trust by a first conversion module, performing a conversion of a format of a data stream from the low trust domain, preferably the ARINC 429 format, into a data format expected by the firewall data processing node.

[0014] - a reverse protocol break processing node is connected to the domain high trust by a second conversion module, performing a conversion of a format of a data stream delivered by the reverse protocol break processing node, preferably the 100 Mbit / s Ethernet format, into a format expected by the low trust domain, preferably the ARINC 664 format, more preferably ARINC 664 P3 or P7.

[0015] - the master data processing node filters a data stream based on a context or based on a priority level.

[0016] the master data processing node executes an intrusion detection application and the detection information generated by said application is addressed to the service node as entries of a log file.

[0017] - any data flow from the low trust domain passes through the node master data processing node, provided it has not been rejected by the firewall data processing node or the protocol break data processing node.

[0018] - in addition to its interface with the low trust domain, the processing node of firewall data has only one output port forcing any operational data stream from the low trust domain to be routed to the protocol break data processing node, and in which, in addition to its interface with the firewall data processing node, the protocol break data processing node has only one output port forcing any operational data stream from the low trust domain to be routed to the master data processing node.

[0019] - any data flow coming from the high trust domain and going to the low trust domain and which does not pass through the master data processing node is routed through the gateway via at least one unidirectional link.

[0020] - the gateway has only one firewall data processing node located at the entrance to the filter chain on the low trust domain side.

[0021] The invention and its advantages will be better understood on reading the detailed description which follows of a particular embodiment, given solely by way of non-limiting example, this description being made with reference to the appended drawings in which:

[0022] [Fig-1] [Fig.l] is a schematic representation of an embodiment preferred avionics security gateway according to the invention; and,

[0023] [Fig.2] [Fig.2] is a timing diagram showing different examples of operation of the gateway in [Fig.l]. STRUCTURE

[0024] Referring to [Fig.l], the architecture of the gateway according to the invention will be presented. In this figure, the bidirectional links are in solid lines while the unidirectional links are in dotted lines.

[0025] The network security gateway 10 is on board an aircraft. It is placed at the interface between a low trust domain 12, or “LTD” domain, and a high trust domain 13, or “HTD” domain, of an avionics IT infrastructure. For example, domain 13 corresponds to the control domain of the aircraft and domain 12 corresponds to another domain on board the aircraft or temporarily connected to the aircraft.

[0026] The gateway 10 has the function of ensuring a secure transfer of data at least from the low trust domain 12 to the high trust domain 13. To this end, the gateway 10 filters the data flows, while being robust to computer attacks seeking to circumvent this filtering.

[0027] Preferably, the gateway 10 is an Ethernet / Ethernet gateway. Alternatively, it is an ARINC 429 / ARINC 429 gateway. More generally, it is an Ethernet and / or ARINC 429 and / or ARINC 664 gateway. (preferably ARINC 664 P3 or P7) on the low trust domain side and Ethernet and / or ARINC 429 and / or ARINC 664 (preferably ARINC 664 P3 or P7) on the high trust domain side.

[0028] The architecture of the gateway 10 is preferably based on a single electronic card 11 carrying several data processing nodes (or “Data Processing Nodes” in English), each node being dedicated to carrying out one or more specific security functions. It is therefore a distributed architecture.

[0029] A node can be any type of device with its own computing resources, memory, and communication port. Preferably, it is a microcontroller, since such a component has low power consumption, which consequently limits heat dissipation problems, a critical issue in the avionics field. Alternatively, it is a programmable logic circuit, such as for example an FPGA (“Field-Programmable Gate Array”).

[0030] The different functions are therefore physically segregated.

[0031] The card 11 thus carries a master node 1. The master node 1 performs the filtering function as such.

[0032] The card 11 also carries several slave nodes. In the embodiment of [Fig.l], four slave nodes are provided, numbered 2, 4, 5 and 6. They perform security, firewall, formatting and reverse formatting functions respectively.

[0033] The board 11 also carries a plurality of conversion devices. In the embodiment of [Fig.l], three conversion devices are provided, numbered 3, 7 and 8.

[0034] These nodes and conversion devices communicate with each other via links.

[0035] The firewall data processing nodes 4, formatting 5, master 1, and 6 reverse protocol breakouts are connected in series to form a data flow filter chain.

[0036] The service node 2 is connected to each of the data processing nodes in the filtering chain.

[0037] The master node 1 is thus “buried” in the heart of the card 11, in the sense that it does not have any direct interface with either of the domains 12 and 13.

[0038] The architecture of the gateway is such that a data flow from the low trust domain 12 is constrained to pass successively through the firewall 4, formatter 5 and master 1 nodes. This constraint is physically achieved by means of the communication links between these nodes: the single operational communication channel leaving node 4 (outside the interface to the low trust domain) leads to node 5 and the single operational communication channel leaving node 5 (outside the interface to node 4) leads to node 1.

[0039] On the low trust level side of the gateway (i.e. nodes 4, 5 and 1), there are indeed communication channels between each of nodes 4, 5 and 1 on the one hand and node 2 on the other hand, but these channels, along links U42, U52 and U12, only allow the transmission of operating information generated by a node to a log file (log file) stored by node 2.

[0040] For communication between an application of the low trust domain 12 and a service of the node 2 (such as a control application using the log file stored by the node 2), the upstream query communications are received by the node 1 and then transmitted after filtering to the node 2 via the link B12, and the downstream response communications are transmitted by the node 2 either to the node 1 via the link B12 (for example, in the case of contextual filtering implemented by the node 1), or directly to the node 4 via the link U24 (to communicate directly and therefore more quickly with the domain 12). Firewall node 4

[0041] The firewall node 4 is positioned in front of the low trust domain 12 from which computer attacks can originate.

[0042] It has at least one input / output port for establishing a bidirectional link with the domain 12. Preferably, it has three ports allowing the establishment of:

[0043] - a first link B4a, direct with domain 12, for example a network of the aircraft during a flight phase. This is, for example, a 100 Mbit / s Ethernet connection;

[0044] - a second B4b link, direct with domain 12, for example connection to maintenance equipment during a ground maintenance phase. This is, for example, a 100 Mbit / s Ethernet link;

[0045] - a third link B34, indirect with domain 12, via the first module of conversion 3.

[0046] The first conversion module 3 makes it possible to convert a data stream coming from domain 12, for example in ARINC 429 format, into a data stream in the required format on link B34. Link B34 is for example an SPI bus or an asynchronous serial link.

[0047] The first module 3 is itself directly connected to the domain 12 by a bidirectional link B3, for example made up of two unidirectional links to ensure bidirectionality.

[0048] The firewall node 4 also has an input / output port for establishing a bidirectional B45 connection with the deformatting node 5.

[0049] The firewall node 4 has an output port for establishing a unidirectional U42 link with the service node 2.

[0050] Firewall node 4 has an input port for establishing a unidirectional U24 link with service node 2.

[0051] Firewall node 4 has an input port for establishing a unidirectional U64 link with reformatting node 6.

[0052] This first node 4 in the data filtering chain ensures a first level of firewall-type filtering. It executes different security verification rules on the data flows received from domain 12.

[0053] If the data stream from domain 12 is accepted by node 4, it is retransmitted to node 5.

[0054] On the other hand, if the flow is rejected, node 4 generates logging information and transmits it to service node 2.

[0055] The firewall node 4 performs, for example, the following filtering:

[0056] - only accept a flow from the low trust domain if it is declared, for example that it contains the identifier of a declared UDP port;

[0057] - check the size of the frames of the flow of the low trust domain, this size must comply with configurable values ​​(minimum size / maximum size);

[0058] - verify that, for a given flow, the frame reception frequency is compliant to values ​​that are also configurable;

[0059] - check that the IP address of the source of the stream conforms to a list of values authorized, this list being configurable.

[0060] In the event that the module 4 rejects a frame from the stream, the header information of this frame is sent to the service module 2. An aggregation of the header information is advantageously carried out by the module 4 when too many frames are rejected. Formatting Node 5

[0061] Node 5 is positioned between node 4 and master node 1 in the data filtering chain.

[0062] It has an input / output port for establishing the bidirectional B45 link with node 4 and an input / output port for establishing a bidirectional B51 link with master node 1.

[0063] Node 5 has an output port for establishing a unidirectional U52 link to service node 2.

[0064] Node 5 provides a second level of filtering by modifying the format of the flows.

[0065] Thus, for a data flow coming from the low trust domain, the module 5 performs a protocol break. It determines the nature of the incident flow, i.e. its format. For example, the data flow relates to a flight plan or to the downloading of software. The node 5 then converts this incident flow into a neutral format. If the protocol break is successful (in the sense that the message contained in the incident data stream is coherent, without syntax errors), the stream is retransmitted, in this neutral format, to master node 1. On the other hand, if the incident stream is rejected, node 5 generates new log entries and transmits them to service node 2 via link U52.

[0066] For a data stream from the high trust domain, module 5 performs a reverse protocol break. It receives a data stream in the neutral format from master node 1. It converts this stream into the required format before transmitting it to firewall node 4.

[0067] The neutral format is not standardized and depends on implementations. Master Node 1

[0068] In the data filtering chain, master node 1 is positioned between deformatting node 5 and reformatting node 6.

[0069] It has an input / output port for establishing a bidirectional B51 link with node 5 and an input / output port for establishing a bidirectional B16 link with node 6.

[0070] It further has an output port for establishing a unidirectional U12 link with the service node 2.

[0071] Master node 1 performs various filters.

[0072] For example, the master node performs a usage domain type filtering, where each data presented in the neutral format of the protocol break is filtered with respect to the value that it is supposed to represent. For example: filter a text type field by eliminating certain special characters; filter a speed field with respect to the values ​​potentially reached by the aircraft; prohibit flows of a certain nature depending on the phases of the aircraft (flight, taxiing, ground maintenance, etc.), where such or such data has no reason to exist.

[0073] For example, master node 1 applies fast filtering or slow filtering so as to respect a latency time adapted to the nature of the incident flow, as identified by node 5. This makes it possible to limit the crossing time of certain so-called critical flows. Master node 1 thus prioritizes critical flows by ensuring processing in a dedicated task, the other, non-critical flows being processed in a general task.

[0074] For example, master node 1 applies contextual filtering. For example, if a first request message circulates from domain 13 to domain 12, master node 1 expects to have to filter the corresponding response message that domain 13 will send to node 12. Master node 1 thus applies a process for verifying the consistency of the exchanges between the two domains.

[0075] The master node 1 advantageously performs tests to monitor the proper functioning of the electronic card 11 and its components. The execution of a test is for example triggered in a ground maintenance phase.

[0076] The master node 1 advantageously performs a filtering of the downloading requests, in particular on the correct format of such requests, the downloading then consisting of importing information for the operation of the gateway (configuration value of the firewall, software update to carry out the protocol break from a data format to the neutral format, etc.)

[0077] For example, in a ground maintenance phase, maintenance equipment is connected to the gateway 10 to update software in the firewall module 4. This equipment transmits a download request, which is therefore filtered by the firewall module 4, which retransmits it to the protocol break module 5, which itself retransmits it to the master module 1.

[0078] Noting that it is a download request, the master node 1 checks a whole series of conditions. Among these conditions there is for example the fact that a piece of equipment is actually connected to the gateway, that the operating phase of the aircraft corresponds to a ground maintenance phase, etc. In the event of a positive verification, the node 1 is able to modify the operating mode of the gateway to switch from a maintenance mode for example to a download mode.

[0079] Node 1 is capable of generating an interrupt signal leading to the restart of the gateway, i.e. to the restart of each of the nodes.

[0080] The master node 1 advantageously executes a HIDS (for “Host-based Intrusion Detection System”) intrusion detection application on all the flows that it filters. For the execution of this application, the intrusion detection application needs environmental data from all the nodes and centralized by the service node 2. Hence the presence of the bidirectional communication link B12 between the master node 1 and the service node 2 for the exchange of this data.

[0081] The detection information generated by this application constitutes entries in the log maintained by the service node 2. This information is sent by node 1 to node 2 via the U12 link.

[0082] Once the flow is filtered, the master node 1 sends it back to the reformatting node 6.

[0083] If the flow is rejected, logging information is generated and transmitted to service node 2 via link U12.

[0084] Master Node 1 is developed with the highest cyber quality assurance level (SAL3). Reverse Format Node 6

[0085] Node 6, downstream of master node 1 in the filter chain, performs a formatting function opposite to that performed by formatting node 5.

[0086] Thus, for a data flow coming from the low trust domain having undergone a protocol break when crossing node 5, node 6 performs a reverse protocol break to move from the neutral format to a format expected by the high trust domain 13.

[0087] Conversely, for a data flow coming from the high trust domain and having to be directed towards node 1, node 6 performs a protocol break. On the other side of master node 1, it will be up to node 5 to perform the reverse protocol break to move from the neutral format to a format expected by the firewall node or low trust domain.

[0088] In the embodiment of [Fig. 1], node 6 has an input / output port for establishing the bidirectional B16 link with master node 1.

[0089] It has an input / output port for establishing a bidirectional B67 link with the second conversion module 7.

[0090] It has an input / output port for establishing a bidirectional B68 connection with the third conversion module 8.

[0091] It has an input / output port for establishing a B62 link with the service node 2. This link is used in one direction from node 6 to node 2. It is only used in two directions during a download from a download device positioned in domain 13.

[0092] Node 6 also has an output port for establishing a unidirectional U62 link to service node 2.

[0093] Node 6 has an output port for establishing the unidirectional U64 link to firewall node 4.

[0094] If the reverse protocol break is successful, the flow is retransmitted to the high trust domain 13.

[0095] On the other hand, if the flow is rejected, node 6 generates logging information and transmits it to service node 2.

[0096] The second conversion module 7 makes it possible to convert a data stream coming from the node 6 into a data stream in the format required by the domain 13. The second module 7 is connected directly to the domain 13 by a bidirectional B7 link, preferably ARINC 664 P3 or ARINC 664 P7, at 100 Mbit / s or possibly more.

[0097] The third conversion module 8 makes it possible to convert a data stream coming from the node 6 into a data stream in the format required by the domain 13. The third conversion module 8 is connected directly to the domain 13 by a bidirectional B8 link, preferably ARINC 429.

[0098] It should be noted that a flow coming from a high trust domain must be transmitted by the reverse formatting node 6 either by the master node 1 or directly to the firewall node 4. The condition for routing a flow by the node 6 results from a configuration of the latter. For example, the routing condition depends on the format of the data of the flow to be processed. Service Node 2

[0099] Node 2 performs various security functions.

[0100] It has an input / output port for establishing the bidirectional B12 link with the master node 1, and an input / output port for establishing the bidirectional B62 link with the node 6.

[0101] It has input ports for establishing connections U42, U52, U12, and U62.

[0102] It has an output port for establishing a unidirectional U24 connection with the firewall module 4.

[0103] Service node 2 ensures the saving of security events and their transmissions in a log file (log file). For example, the log file is saved in SYSLOG format.

[0104] The service node 2 ensures the backup and transmission of data associated with the proper functioning of the gateway. This function is for example known to those skilled in the art under the name “BITE” (“Built In Test Equipment”). This involves carrying out suitable tests on the various components of the gateway cyclically or as a function of triggering events.

[0105] The service node 2 is responsible for download exchanges with external equipment, once the transition to download has been validated by the master node 1. To respond to a request to download the log file sent by an application in the low trust domain 12 and validated by the node 1, the node 2 can transmit the data via the B12 link, or when there is a simple query, via the U24 link directly to the firewall node 4. The U24 link is thus used to respond efficiently to simple download requests.

[0106] Internal communications on the card 11 use separate technologies, for example Ethernet and serial. For example:

[0107] - the bidirectional links B45, B51 and B16 are Ethernet data buses, preference to IGbit / s;

[0108] - the bidirectional links B62 are Ethernet data buses, preferably 100 Mbit / s;

[0109] - link B34 is a synchronized bus (SPI for “Serial Peripheral Interface”) or an asynchronous serial link;

[0110] - links B67 and B68 is a PCI or PCI Express bus;

[0111] - and the different unidirectional links are for example data buses serial, preferably synchronized (SPI for “Serial Peripheral Interface”), but can alternatively be asynchronous.

[0112] This specificity makes it possible to reinforce the non-bypass properties of the filtering.

[0113] The use of the Gigabit Ethernet protocol along the filter chain ensures limited traversal times between domains 12 and 13 so as to obtain traversal times of less than 50ms, in accordance with avionics requirements. Indeed, the Ethernet protocol allows a flow to be resent very quickly after receiving the last fragment of a message. Without rapid retransmission to the next node, the gateway's traversal time would be significantly impacted, particularly for long fragmented messages, because the protocol break can only be made on a complete message and not a fragment of it. The internal links along the filtering chain therefore have a higher bandwidth than the connections connecting the gateway to the high and low trust domains.

[0114] All the nodes provided on the card are synchronized by the same clock, which is under the control of the master node 1. In this way, with simple software sequencers where each node is shifted in the execution of its tasks so that the end of a task of a node is synchronized with the start of the task of the next node along the filtering chain, the crossing time of the gateway is optimized by taking into account the time of the processing carried out independently by each of the nodes arranged in series along the filtering chain. OPERATION / USE

[0115] [Fig.2] illustrates several possible operations of the gateway 10 just presented.

[0116] According to a first operation 100, the master node 1 performs a simple filtering of the data flows circulating from the low trust domain 12 to the high trust domain 13.

[0117] A request message is sent from domain 13 to a server in domain 12. The gateway 10, which is the cut-off point between the two domains, receives the request message.

[0118] The request message is first received (step 110) by node 6, which forwards it (112) directly and without format modification to firewall node 4 via link U64. Node 4 forwards it (114) in turn to domain 12.

[0119] On domain 12, the request message is routed to the recipient server, which prepares a suitable response message.

[0120] The response message is returned from the low trust domain 12 to the high trust domain 13. The response message therefore passes through the gateway 10.

[0121] More precisely, the response message is received (115) by the firewall node 4. After positive verification, the node 4 retransmits it (116) to the formatting node 5.

[0122] This performs the protocol break and, if successful, retransmits (117) to the master node 1 the response message transcribed in the neutral format.

[0123] Upon receiving the response message, master node 1 applies appropriate filtering treatments.

[0124] In case of positive filtering, the response message is transmitted (118) by the master node 1 to the reverse formatting node 6. The latter converts the response message according to the required format and retransmits it (119) on high trust domain 13.

[0125] According to a second operation 200, the master node 1 performs contextual filtering, in this case a consistency check between request and response messages.

[0126] A request message is sent from the high trust domain 13 to a server in the low trust domain 12. The gateway 10, in the cut-off between the two domains, receives the request message.

[0127] This request message is received (step 210) by the reverse formatting node 6. Taking into account, for example, the value of a field in the header of the request message, the node 6 applies a protocol break to the request message and retransmits (211) the request message in the neutral format to the master node 1.

[0128] Noting that it is a request, the master node 1 memorizes for example the identifier of this request to subsequently carry out the consistency check.

[0129] The master node 1 retransmits (step 212) the request message to the formatting node 5, which applies a reverse protocol break and retransmits (213) the request message in the adapted format to the node 4.

[0130] The latter in turn retransmits (214) the request message to domain 12.

[0131] On domain 12, the request message is routed to the destination server, who develops a suitable response message.

[0132] The response message is returned from the low trust domain to the high trust domain. The response message therefore passes through the gateway 10.

[0133] The response message is returned from the low trust domain 12 to the high trust domain 13. The response message therefore passes through the gateway 10.

[0134] More precisely, the response message is received (215) by the firewall node 4, which retransmits it (216), after verification, to the formatting node 5.

[0135] This performs the protocol break and, if successful, retransmits (217) to the master node 1 the response message in the neutral format.

[0136] Upon receiving the response message, master node 1 applies the appropriate filtering processes as well as the consistency check. To do this, it checks whether the identifier contained in the response message corresponds to the identifier contained in the request message previously processed by master node 1.

[0137] In the event of a positive verification, the response message is retransmitted (step 218) by the master node 1 to the node 6, which, after reverse protocol break, returns it (219) to the high trust domain 13.

[0138] In case of negative verification, the response message is rejected by the master node 1 and an entry relating to the failure of the coherence processing is added to the log file maintained by the service node 2.

[0139] According to a third operation 300, the low trust domain 12 applies to the gateway a download request message, for example with a view to downloading a software update for the firewall node 4.

[0140] A download request message is received (step 310) from the low trust domain 12 by the firewall node 4.

[0141] After positive verification, the firewall node 4 transmits it (311) to the formatting node 5.

[0142] Node 5 performs the protocol break and retransmits (312) a download request message in neutral format to master node 1.

[0143] The master node 1 analyzes the download request message. In particular, it checks that the current operation of the aircraft is compatible with a switch to a gateway download mode. Indeed, for example, if the aircraft is in flight, the master node 1 rejects the download request because this risks harming the overall operational safety of the aircraft.

[0144] In case of positive verification, the master node 1 switches the gateway into a download operating mode.

[0145] It transmits (313) a download management command message to service node 2, but via node 6.

[0146] Noting that this is a message intended for node 2, node 6 routes (314) the control message to node 2 along link B62.

[0147] Upon receipt of the control message, the service module 2 manages the download. The file is downloaded from domain 12 to node 2 via nodes 4, 5, 1 and 6.

[0148] For example, node 2 saves (315) the downloaded file in a flash memory of firewall node 4.

[0149] At the end of the download, node 2 indicates to master node 1 the end of the operation.

[0150] The master node 1 then commands a restart of the gateway 10, during which the firewall node 4 resets the contents of its RAM with the information contained in the flash memory associated with it, and consequently with the update file just downloaded. BENEFITS

[0151] By physically segregating the different functions, the gateway just presented achieves the security levels required for the avionics domain, which would not be the case with simple software segregation.

[0152] The gateway architecture, based on different physically independent nodes, makes it possible to simplify the proofs of a good development of the security functions. For example, according to the ED-203A standard, the master nodes 1 and protocol break 5 are advantageously developed according to the highest level, SAL3; the firewall node 4 according to the intermediate level, SAL2; and the service nodes 2 and reverse protocol break 6 according to the lowest level, S AL 1.

[0153] In particular, the protocol break must be developed in SAL3 to be able to achieve a good level of filtering with the highest level of cybersecurity quality assurance.

[0154] It will be noted that these last two nodes, since they are located downstream of the master node 1 and all the data flows that they receive are first filtered by the firewall, protocol break and master nodes, benefit from the criticality level of the high criticality domain.

[0155] The service node often presents a great complexity. It would be complicated and expensive to develop it according to the SAL2 level. The invention therefore makes it possible to relax the development constraints on this component, while guaranteeing that it cannot be used to circumvent the filtering of flows, which always return to the master node.

[0156] The architecture therefore makes it possible to isolate tasks according to their criticality and their associated quality assurance levels, while ensuring a point of passage for the different flows to ensure systematic filtering. The gateway makes it possible to carry out high-quality filtering using different technologies depending on the flows.

[0157] The proposed solution ensures that all data flows from the low security domain pass through the master node. This architecture ensures that the filtering function is not circumvented.

[0158] With this architecture, the traversal times can be quite low while ensuring non-circumvention properties required by the high level of cyber-security quality assurance required.

[0159] According to this architecture, the master node is not in direct relation with the low trust domain: it only receives flows passed through two filters, that carried out by the firewall and that carried out by the protocol break.

[0160] In the preferred embodiment presented above, the different data processing nodes are integrated on the same electronic card, which leads to a solution having a reduced form factor, which is advantageous insofar as volume constraints are strong constraints in the avionics field. Alternatively, the processing nodes are located on several electronic cards connected to each other in a suitable manner.

[0161] The modular aspect facilitates the development, certification, maintenance, and updating of the gateway.

[0162] It should be noted that this gateway only has one per fire, placed at the input connected to the low-trust network domain.

[0163] It should also be noted that the gateway is configurable, which allows the various filtering functions to be configured according to current threats.

Claims

Claims

1. Network security gateway (10) intended to be carried on board an aircraft to connect a low trust domain (12) and a high trust domain (13) of an avionics IT infrastructure, the gateway providing a plurality of security functions, each function being performed by a data processing node, the gateway comprising, connected in series along a filtering chain of a data stream received from the low trust domain: - a firewall data processing node (4); - a protocol break data processing node (5); - a master data processing node (1);and, - a reverse protocol break data processing node (6), the gateway further comprising a service node (2) connected to each of the data processing nodes of the filtering chain, the service node (2) performing various security functions, in particular the storage of a log file and centralization of environmental data from all the nodes; the different data processing nodes being physically segregated, the master data processing node (1) executing an intrusion detection application using the environmental data centralized by the service node (2) and the detection information generated by said application being addressed to the service node (2) as entries in the log file.;

2. Gateway according to claim 1, in which the nodes of the filtering chain are connected by bidirectional links, preferably in Ethernet format, more preferably in 1 Gbit / s Ethernet format, having a bandwidth greater than that of the connections making it possible to connect the gateway to the high and low trust domains.

3. Gateway according to any one of claims 1 to 2, wherein the service node (2) is connected to the plurality of nodes of the filtering chain by unidirectional links, preferably in serial format, preferably still in synchronized serial format.

4. A gateway according to any one of claims 1 to 3, wherein the gateway constitutes an Ethernet and / or ARINC 429 and / or ARINC 664 interface with the high trust domain (13) and an Ethernet and / or ARINC 429 and / or ARINC 664 interface with the low trust domain (12).

5. Gateway according to any one of claims 1 to 4, wherein the firewall data processing node (4) is connected to the low trust domain (12) by a first conversion module (3), performing a conversion of a format of a data stream from the low trust domain (12), preferably the ARINC 429 format, into a data format expected by the firewall data processing node (4).

6. Gateway according to any one of claims 1 to 5, wherein the reverse protocol break processing node (6) is connected to the high trust domain (13) by a second conversion module (7), performing a conversion of a format of a data stream delivered by the reverse protocol break processing node (6), preferably the 100 Mbit / s Ethernet format, into a format expected by the low trust domain (12), preferably the ARINC 664 format, more preferably ARINC 664 P3 or P7.

7. A gateway according to any one of claims 1 to 6, wherein the master data processing node (1) filters a data stream based on a context or based on a priority level.

8. A gateway according to any one of claims 1 to 7, wherein any data flow from the low trust domain (12) passes through the master data processing node (1), provided it has not been rejected by the firewall data processing node (4) or the protocol break data processing node (5).

9. A gateway according to any one of claims 1 to 8, wherein, in addition to its interface with the low trust domain (12), the firewall data processing node (4) has only one output port forcing the routing of any operational data stream from the low trust domain (12) to the protocol break data processing node (5), and wherein, in addition to its interface with the firewall data processing node (4), the protocol break data processing node (5) has only one output port forcing the routing of any operational data flow from the low trust domain (12) to the master data processing node (1).

10. A gateway according to any one of claims 1 to 9, wherein any data flow from the high trust domain (13) to the low trust domain (12) and which does not pass through the master data processing node (1), is routed through the gateway via at least one unidirectional link.

11. Gateway according to any one of claims 1 to 10, comprising only a single firewall data processing node (4) located at the input of the filtering chain on the side of the low trust domain (12).

Images