Aviation security - Lessons to learn from PlaneSploit

Question

A somewhat related question has already been asked (What would one need to do in order to hijack a satellite?), only at a more abstract level.

Now we have a presentation by Hugo Teso from n.runs AG hitting the headlines and making some pundits from within the Beltway possibly blush, which does bring critical infrastructure security into the limelight, threatened not by Advanced Persistent Threats but by lone attackers.

The essence of the exploit:

• two completely unsecured wireless air-to-ground comms protocols (ADS-B, ACARS), with the former being part of the NextGen automated air traffic control system in development by FAA and the industry, and the latter quite outdated;
• a simulated plane as a hardware + software setup assembled from mostly authentic parts from Rockwell Collins, Honeywell, Thales and whatnot (pretty much the biggest fish in the pond), software reportedly written in Ada;
• transceiver implemented as software-defined radio;
• ability to subvert on-board flight management system, including redirecting planes and presenting false information to the crew.

The question is simple: What practical security lessons should be learned by aviation regulators?

In particular, what are the recommendations on organizing complex system development and security testing over and beyond the procedures already in place?

---

Related multimedia (turns out it is a recurring topic):

• Spoofing ADS-B
• Presentation on ADS-B at DEF CON 20
• DEF CON 18: Air traffic control insecurity 2.0
• DEF CON 17: Air traffic control and ADS-B

EDIT: Chris Roberts is being grilled by the Feds on alleged hacking of FMS from In-Flight Entertainment boxes. See the question at Aviation SE: https://aviation.stackexchange.com/questions/14818/are-commercial-aircraft-designed-with-a-shared-data-network

Answer 1

@ewanm89 is entirely correct. Securing the connection between ground control and a plane should be no different from securing any regular connection.

The main issue is that the protocol designers are relying on security by obscurity. Obscurity through the relatively unknown protocol being used. Obscurity through what used to be relatively difficult to obtain equipment. Obscurity through the fact that having enough resources to mount a feasible attack used to be impractical.

Of course, this is no longer the case. In the era of state sponsored cyber attacks (God, I hate that term), resources are no longer an issue. Reverse engineers have taken apart the protocol being used. Obscurity is no longer enough.

The proper solution is to build proper encryption and authentication measures into the protocol being used. This isn't something novel, the internet has been using such protocols for more than a decade. (See: SSL/TLS). This will prevent attackers from simply grabbing the data being sent from the air, modifying it and sending it.

This sort of attacks isn't limited to aviation systems. There have been plenty of similar ones on SCADA systems as well.

Answer 2

I'm no pilot, or an aviation expert, but I'm going to stick my neck out on this one and call it a zero substance FUD and an attempt at using our general ignorance on avionic systems as a cheap way of advertising one's so called security expetise.

I've read through the presentation (if reading is a proper term for browsing through a few only seemingly connected slides that don't even care to explain much anything beyond buying stuff off eBay), and I see no evidence of this alleged vulnerability to be a direct threat to aviation safety. In fact, there's no evidence in the presented documentation that such test system was even assembled, let alone that it would be capable of doing any damage. Sure, I can see how it could be made to work, and potentially short-time (before detected and removed) disturb a few flight related systems. These however wouldn't be in any way related to aviation safety, merely a temporary nuisance to supporting logistics.

^{The PlaneSploit presentation is about as serious as finding a diagram of this LEGO airplane in the Boeing 747 flight manual.}

That said, I would require a bit more than a few presentation slides littered with speculation, to be convinced it presents any real danger. What systems are at risk? Let's see what these ADS-B and ACARS are actually all about. For example:

ADS-B Relationship to surveillance radar:

Radar directly measures the range and bearing of an aircraft from a ground-based antenna. The primary surveillance radar is usually a pulse radar. It transmits a continuous high power sequence of pulses. Bearing is measured by the position of the rotating radar antenna when it receives the reflected beam that comes from the body aircraft; and range is measured by the time it takes for the radar to receive the reflected beam. Primary surveillance radar does not require any cooperation from the aircraft. It is robust in the sense that surveillance outage failure modes are limited to those associated with the ground radar system. Secondary surveillance radar depends on active replies from the aircraft. Its failure modes include the transponder aboard the aircraft. Typical ADS-B aircraft installations use the output of the navigation unit for navigation and for cooperative surveillance, introducing a common failure mode that must be accommodated in air traffic surveillance systems.

• Primary surveillance radar (PSR). Independent? Yes: surveillance data derived by radar. Cooperative? No: does not depend on aircraft equipment.

• Secondary surveillance radar (SSR). Independent? No: surveillance data derived by aircraft. Cooperative? Yes: requires aircraft to have a working ATCRBS transponder.

• Automatic dependent surveillance (ADS-B) Independent? No: surveillance data provided by aircraft. Cooperative? Yes: requires aircraft to have working ADS-B function.

^{Excerpt taken from Wikipedia - Automatic dependent surveillance-broadcast. Feel free to read the rest of it.}

The rest of the Wiki reads in much the same fashion - it is a tertiary system that's not influencing on-board crew, ground control crew and/or any other flight safety related decision making!

I would still consider what @TerryChia said before me a good advice, don't get me wrong. Of course there is a point in securing any communications, even though it will most certainly add to data overhead. What I wanted to show is that this presented case isn't something a general audience should be worried about. It can be a nuisance to ground based logistics and support, and it might give pilots something to play with and report potential problems to ground control when they don't have anything better to do. But it most certainly won't make then turn the plane around, turn it into an electrical storm, land at the wrong airport, or even unintentionally forward forged destination weather conditions to their passengers so they disembark the airplane in t-shirts and shorts in the middle of a snow storm. Other, more reliable systems will alert them when the data these tertiary systems are producing are being tempered with, or are otherwise unreliable for whatever reasons. They can then choose to ignore them, change communications channel, or disable them altogether.