pax wifi networks again...

[deptrai]

seems like the GAO in a report is critical of having avionics and pax wifi on the same physical network, only separated by software firewall features, not actually physically separate ("air gapped") networks.

Wired creats a sensationalist headline out of this Hackers Could Commandeer New Planes Through Passenger Wi-Fi | WIRED (http://www.wired.com/2015/04/hackers-commandeer-new-planes-passenger-wi-fi/)

the faa was critical to this some years ago, Federal Register, Volume 73 Issue 1 (Wednesday, January 2, 2008) (http://www.gpo.gov/fdsys/pkg/FR-2008-01-02/html/E7-25467.htm) and there is an old thread here

http://www.pprune.org/tech-log/307162-your-787-controlled-seat-34g.html

its probably reasonably safe, and this is not a major concern for me, but I simply dont get why one would design it that way? What were the engineers thinking? Cost savings? if so, must be microscopic? Could someone enlighten me here, I cant see any possible advantages to let critical avionics and pax entertainment systems share infrastructure, there is no need for his, and it cant be that hard to just make a physically separate network for pax wifi?

[EEngr]

why one would design it that way?Creeping featurism.

Today, there are a limited number of functions that require a data flow from avionics/flight deck systems to the pax network. Current examples are public address systems and the cool real time map of the aircraft's location. But at some point in the future, someone might have a neat feature that they want to add. And rather then having to install a dedicated hardware interface, it can be done with a software revision.:8

[deptrai]

thank you for the explanation

[EEngr]

... a 'security researcher' was escorted off a flight (https://securityledger.com/2015/04/hacker-on-a-plane-fbi-seizes-researchers-gear/) for making statements (tweets) that he could hack into his flight's cockpit systems.

The consensus in the s/w community is that this guy is some sort of idiot. Making jokes about this sort of thing isn't the same as actually doing it. And his remarks may not add up to more than geek d:mad:k-swinging.

He has raised some interesting points about aircraft network security in the past as a researcher. But seeing as how he might never be let near one again, his expertise is a moot point.

[dClbydalpha]

An aircraft avionics suite is not like anything most "hackers" are used to and they know it. The article does not raise any interesting points about aircraft network. It seemed to be another rubbish in-joke that backfired. Just like the musician who said he had a machine gun in his violin case.

Flight critical systems do not use Ethernet to transfer data.
Real time operating systems in general do not leave open "ports" vulnerable to attack. All dataflow is scheduled and known.

Access to Ethernet even beyond the firewall will only give access to non-critical data. So perhaps change a bit of weather data, corrupt a maintenance log, change incoming messages in general make a bit of a nuisance of themselves, but not take over the aircraft.

[Denti]

I guess it is more complicated. In modern aircraft like 787 and A350 apparently there is only one physical network installed throughout the aircraft that carries both IFE/Wifi data as well as all flight critical data (FBW, etc.). Granted, on a protocol layer they are separated and flight critical data has priority, but there is a (slim) chance of interference.

Added to that airlines to love featuritis as well and i know some are installing or already using bi-directional bluetooth connectivity between cots EFBs (iPads for example) and the FMC/FMGC. Since those bluetooth connections can be used by other devices as well they are open to interference from a wide variety of problems.

[dClbydalpha]

It may not seem it but this is a serious subject. This fuels the scaremongers, so let's not guess. I have never seen an architecture where safety critical data is sent over Ethernet, I can't even conceive how one would be certified. If anyone can point me to one that does I would be grateful. I add I have no experience of the 787 or 350 avionics implementations so am open to new information.

If data is passed to things like an FMC then it is controlled at point of entry by the critical software and usually has to be checked and confirmed by the operator. As I said previously it is possible for a talented hacker to make a nuisance of themself but taking over an aircraft would need something very much more than being able to access Ethernet.

[deptrai]

looking into this, the RTOS "common core system" of the B787 hosts 80-100 aplications, even including lav and galleys management.

and exactly as EEngr said, this architecture was chosen because of "featurism": "Boeing feels that this approach will reduce the "cost of change" [..]. When Boeing adds new features down the road, it can use the automated tools to update the configuration, so that the additional work required for approval will be much smaller. "

Flight critical systems do not use Ethernet to transfer data.

"The majority of the display applications are run on the general processing modules of the CCS. The display information is then sent over to our graphics generation module [GGM], housed in the CCS cabinets. It's sent using ARINC 661 over Ethernet"

One could argue how critical the displays are, and I don't see any vulnerabilities here, no cause for sensationalist headlines, I was just surprised why this "connected"/"shared" architecture was chosen, and EEngr explained that. It's something new, and therefore interesting.

I was quoting from http://www.aviationtoday.com/av/commercial/B787-Cockpit-Boeings-Bold-Move_1181.html#.VTI-E1XLfIU

Speaking of vulnerabilities, Im not sure why anyone with bad intentions would even consider "hacking" through pax wifi, a much easier way to manipulate an aircraft would be to transmit false GPS radio signals, in my opinion this is feasible. Same with TCAS, it could be fed false information from a small transmitter, it's not rocket science. These to paths (essentially is radio interfaces feeding data into aircraft systems) are unencrypted, open, and well documented. But realistic concepts of "false radio signals" probably sells fewer newspapers than vague nonsense about "hacking".

[dClbydalpha]

Deptrai, you seem genuinely interested in the topic, so I'll be a bit more specific with my terms.

People think of ethernet as the thing that connects computers and the internet. As Denti has said, data is exchanged by a protocol on top of ethernet, which essentially is the "hardware". The use of the term ethernet within avionics is therefore somewhat misleading. On an aircraft data can be transfered via "ethernet" more properly using TCP/IP or UDP over IEEE802 ethernet, but this is not (as I say as I am aware of) ever used for flight critical data because simply it is not deterministic. The ethernet hardware is capable of transferring data at much higher rates than traditional avionic databuses, therefore that hardware was used to create a deterministic standard, AFDX ARINC 664. Basically AFDX can run on ethernet hardware, but any attempt for "ethernet" to get into a live AFDX network as data will be rejected, it would be like putting a letter in a post box without an address and hoping it gets there. So a "hacker" will not be able to break into the AFDX data simply by using standard "ethernet" techniques.

The other part required to understand is that the Boeing CCS is the latest implementation of an integrated modular architecture. At the heart is a bank of processing that runs in an environment that is not at all like your home PC, it is highly partiotioned with very strict control of the common resources. Those function modules that require a level of integrity are also carefully coded and tested. The combination of the RTOS and the software process means that these modules are not vulnerable to the same type of "hacking" that say a bank computer system might.

So the question you ask of why go to such an architecture can be answered by the numerous papers out there on integrated modular architectures. It isn't new, probably it is more noticeable because of the gowth in demands for IFE.
In summary IMA is good because of
scalability - it is easily resized to transfer between different products
supportability - in may cases updates require only small software modules to be replaced
flexibility - introduction of new functions becomes a basic software and configuration task, not laying in new looms.
installation - electrical, cooling and structural provisions are all simpler as they are in one place. Not to mention EMC, lightning protection maintenance access.

Why to avoid IMA,
certification - the certification task involves a lot more complicated interactions than simply certfying federated boxes one at a time.

standardisation - getting the individual suppliers to agree to implement a standard is difficult for so many business reason - I suspect that is why it has been a long time coming.

I restate what I said earlier. I have not seen any architecture where flight critical data is "hackable". None of the referenced material shows that the 787, 777-X or 350 put the flight critical functions, their primary flight instruments, FADECs or FBW applications, solely on shared resources. If anyone has information to the contrary I am genuinely interested.

Nothing that I have read in any of the referenced material so far changes my opinion that a random hacker with a laptop could do anything other than become a nuisance.

[dClbydalpha]

Just read your edit Deptrai,

GPS can certainly be jammed. It is probably quite difficult to misdirect a GPS from within the aircraft. Cheap GPS transmitters are definitely an issue to aviation.
TCAS is a bit more clever than just reading the data it relies on interrogation and response.

[deptrai]

Thank you for your detailed response. I agree any "attack" through IFE/wifi would - if at all possible - be limited to being a nuisance. Still highly unlikely though.

An interesting (to me) sideline is that an Arinc 653 scheduler, which allows the different applications/partitions/domains to coexist in isolation without affecting each other, has been incorporated into Xen, a common open source hypervisor.

As for the gps spoofing, it's not trivial, but a group of engineering students put together a device to spoof signals to the gps receiver of a "superyacht", and it's autopilot altered course. It's been done to UAV's too. It's not impossible. I would see it as one of the weaker point of aircraft systems, in the context of "hacking". Of course, GPS is not the only source of position informantion in an aircraft, but civilian GPS is in no way "super-secure"

Spoofing TCAS is probably much trickier for several reasons - some people know because they have tried this too :) as far as I understand it uses angle-of-arrival as well as round trip transponder delay - and it also has built-in protections against RA's that would command pilots to fly into the ground.

Not easy, but somewhat more feasible than "pax-wifi hacking" in my opinion, which seems to be hype and hot air, a movie plot.

[dClbydalpha]

That's interesting. A 653 scheduler as open source may create some cheap development opportunities. I doubt it would be used in a certified product, certainly for creating virtual machines on the bench for concept testing without having to invest in a developer's license, it may bring some fresh ideas to the party.

As you say multiple systems protect against spoofing.

[deptrai]

The ARINC 653 scheduler was funded by DARPA, a project aimed at satellites. Now that it's there out in the "open", certifiable, yes, some people who might not otherwise get an opportunity to "play" with aviation technology have a chance to get hands-on experience and possibly contribute something. Not totally "free", some premium tools for a development environment are sold at a price, but accessible. I stumbled across it when I was looking for a virtual lab, a network simulation to better understand AFDX (which I didn't find).

From the specs I see it's impossible to play any classic ethernet tricks like manipulating ARP tables, switches have a fixed table of MAC addresses, this is not a security feature, but to lower latency, in a network where all components are known. Switches also do some kind of traffic policing as I understand, again not for "anti-hacker security", but to ensure bandwidth is available I assume. Anyway, it was interesting to learn more, I had a rudimentary understanding of engines, hydraulics and electrical systems etc, but not the new AFDX parts of aircraft :) Frankly I don't see how anything could be "hacked" without physical access, without connecting hardware in, say, the avionics bay. And that is not the "hacking" the GAO or newspapers had in mind.

The wildest scenario I could imagine for "wifi hacking" (without physical, hands-on access to critical components) is, that there could be undocumented backdoors or protocols in the satcom equipment (to which pax terminals already have 2 way communication) left behind by careless manufacturers, for their convenience (happens more often than it should). Which again is not critical for flight. And even the worst kind of "hacking" scenarios I could imagine as feasible, signal spoofing, are essentially all about altering information as it is presented to pilots, and pilots routinely deal with unreliable information. The latter is probably the biggest advantage they have over automation, and the reason why they are there.

I have no problems understanding the benefits of integrated modular avionics, although I can understand that at first sight people can be dumbfounded why pax entertainment services need to be physically connected to "avionics" (it's labelled IMA, not integrated modular everything). An "air gap" is a good practice for security, yet I think what some people, including me, can misunderstand, is that they interpret the concept of an "air gap" too literally, and get confused by repeated somewhat misleading news reports.

[AJW709]

Forget hacking through Wifi, Is it possible to hack via IFE boxes under the seats?

See this article on CNN: Fearing United plane was hacked, FBI pulls security expert off flight - Apr. 17, 2015 (http://money.cnn.com/2015/04/17/technology/security/fbi-plane-hack/index.html)

[dClbydalpha]

Spot on Deptrai ... most of the hardening is a consequence of having a highly structured system necessary both for efficiency and to be testable to get through certification. An attack on an aircraft's critical systems would have to be very determined for many of the reasons you've stated.

You mention backdoors, for critical software all code is reviewed and there must be no redundant or unexectued code. All code must be fully documented. All branches must be executed in test. This leads to the rather interesting situation that within development it might be useful to have the ability to change gains etc. To do so you password protect the data entry. Because the password routine is in the code then it has to be tested, to test it you need to document it, to document it you need to publish the password. So password protection for the Exp. FTEs is more of a gentlemen's agreement ;) Needless to say the production s/w has to have such features removed!