I was flying about a year ago and was messing with the in flight entertainment in a 787. It was pretty easy to figure out how to get to a boot menu in the in flight entertainment. I was thinking "huh, this seems like maybe a way in". Seeing how the in-flight displays navigational data it must be on the network as the flight systems. I'm sure there is some kind of segregation but its probably not ultimately secure.
Software Vulnerabilities in the Boeing 787
41–48 of 48 posts
Re: Software Vulnerabilities in the Boeing 787
#42Earlier quoted context omitted.
If Boeing decides to cut costs by using a single network for their entertainment, communications and flight control, who is there gonna be to tell them no? You would assume there is some oversight by independent security researchers who review these planes security, but this assumption seems unsubstantiated. In reality, how is this separation of critical networks looking like exactly? MAC address filters? Are they ai…
Boeing actually attempted that on 787,with some VLAN trickery. FAA caught it and forced them to redesign the setup. As for actual AFDX networks - they have hardcoded forwarding tables and no MAC learning, and separation between networks tends to use data diodes
As a network engineer it is terrifying that they would try this. Also, even if you have no MAC learning its trivial to sniff the MAC on an endpoint and then spoof it. You would really need pubkey based encryption where the key is stored in secure chips on every endpoint to know for sure what each device is connected to.
Re: Software Vulnerabilities in the Boeing 787
#43Earlier quoted context omitted.
you work for boeing or the FAA
Or one of Boeing's many subcontractors.
Re: Software Vulnerabilities in the Boeing 787
#44Earlier quoted context omitted.
Boeing actually attempted that on 787,with some VLAN trickery. FAA caught it and forced them to redesign the setup. As for actual AFDX networks - they have hardcoded forwarding tables and no MAC learning, and separation between networks tends to use data diodes
As a network engineer it is terrifying that they would try this. Also, even if you have no MAC learning its trivial to sniff the MAC on an endpoint and then spoof it. You would really need pubkey based encryption where the key is stored in secure chips on every endpoint to know for sure what each device is connected to.
Companies do these things all the time and in other industries they get away with it. It would be nice if other industries would have similar strict audits and requirements.
Re: Software Vulnerabilities in the Boeing 787
#45Earlier quoted context omitted.
> These systems are entirely separate, including the electricity that controls the systems. This is not what Boeing said to the FAA 12 years ago when they asked to certify their network architecture > The proposed architecture of the 787 is different from that of existing production (and retrofitted) airplanes. It allows connection to and access from external sources (the public Internet) and airline operator network…
Nothing you've quoted here disagreed with what the statement from the parent
> previously isolated Aircraft Control Domain and Airline Information Services
Re: Software Vulnerabilities in the Boeing 787
#46Earlier quoted context omitted.
Boeing actually attempted that on 787,with some VLAN trickery. FAA caught it and forced them to redesign the setup. As for actual AFDX networks - they have hardcoded forwarding tables and no MAC learning, and separation between networks tends to use data diodes
As a network engineer it is terrifying that they would try this. Also, even if you have no MAC learning its trivial to sniff the MAC on an endpoint and then spoof it. You would really need pubkey based encryption where the key is stored in secure chips on every endpoint to know for sure what each device is connected to.
the difference is that AFDX is a "closed" network. If you attached anything to it directly, you're already past the security boundary, as timing and reliability is more important than verifying identities in it.
Re: Software Vulnerabilities in the Boeing 787
#47Earlier quoted context omitted.
Where can one read about the 787 data diodes?
You can read about the fact that there are NO data diodes on the FAA website > The proposed architecture of the 787 allows connection to and access from external sources (the public Internet) and airline operator networks to the previously isolated Aircraft Control Domain and Airline Information Services Domain. > Capability is proposed for providing electronic transmission of field-loadable software applications and…
That's a request for comments from before 787 got its type certificate - I'd like to see the result, as I do recall there being a request to redesign the networks due to "not enough separation". Even HN talked about it.
I can't find the "work-in-progress" reports for type certification regarding the network, but the special conditions involve:
> The applicant shall ensure system security protection for > the Aircraft Control Domain and Airline Information > Domain from access by unauthorized sources external to > the airplane, including those possibly caused by > maintenance activity. The applicant shall ensure that > security threats are identified and assessed, and that > risk mitigation strategies are implemented to protect the > airplane from all adverse impacts on safety, > functionality, and continued airworthiness.
Re: Software Vulnerabilities in the Boeing 787
#48Earlier quoted context omitted.
AFDX protocol stack is unidirectional with no ACKs or anything like that, which makes use of physical data diodes trivial.
That is false. Apart from the hard-coded and restrictive network configuration, AFDX is basically UDP/IP. There are many uses of bidirectional application protocols (like TFTP).
unidirectional nature of the communication protocols means that AFDX-compatible application can be easily firewalled for cases such as reporting data to maintenance network, as I understood from Boeing's response.
Electronic Flight Bag being part of maintenance network is not something good, though.