The FAA Is Arguing for Security by Obscurity

In a proposed rule by the FAA, it argues that software in an Embraer S.A. Model ERJ 190-300 airplane is secure because it's proprietary:

In addition, the operating systems for current airplane systems are usually and historically proprietary. Therefore, they are not as susceptible to corruption from worms, viruses, and other malicious actions as are more-widely used commercial operating systems, such as Microsoft Windows, because access to the design details of these proprietary operating systems is limited to the system developer and airplane integrator. Some systems installed on the Embraer Model ERJ 190-300 airplane will use operating systems that are widely used and commercially available from third-party software suppliers. The security vulnerabilities of these operating systems may be more widely known than are the vulnerabilities of proprietary operating systems that the avionics manufacturers currently use.

Longtime readers will immediately recognize the "security by obscurity" argument. Its main problem is that it's fragile. The information is likely less obscure than you think, and even if it is truly obscure, once it's published you've just lost all your security.

This is me from 2014, 2004, and 2002.

The comment period for this proposed rule is ongoing. If you comment, please be polite -- they're more likely to listen to you.

Tags: , ,

Posted on June 26, 2017 at 6:59 AM • 39 Comments

Comments

William Woody • June 26, 2017 7:32 AM

On reading the proposed FAA rule (and knowing something about the way avionics are designed) it sounds to me what Embraer is doing with their new aircraft is introducing some systems (probably the in-flight entertainment system) which uses off-the-shelf operating systems (probably Linux), and have provided a gateway between the entertainment system ("the passenger-entertainment domain") and the aircraft monitoring domain for control purposes. (The "aircraft safety domain".)

And it seems they are requiring the FAA to establish additional safety requirements--specifically, requiring a "security-risk assessment". (Also, see item 1 of the "special conditions" at the end.)

Previously aircraft have physically never connected the passenger-entertainment domain and the aircraft safety domain: most modern aircraft run two completely separate and physically disconnected systems. The only physical way to access the aircraft safety domain was through the cockpit and through external access panels that can only be opened on the ground. Also note that most modern aircraft's flight control services are on a separate physical system--generally controlled through hydraulics assisted with control cables or through electronic signals sent through separate cables that do not interact with the aircraft safety domain. (This is so that the aircraft remains under pilot control even if the in-flight electronics blow up.) Modern aircraft are also required to provide a backup mechanical compass, mechanical air speed indicator and mechanical attitude display. This allows an aircraft with a complete failure of all avionics to receive guidance from air traffic control and land safely.

I think this is a good thing because the FAA is realizing that aircraft have in-flight network systems and they must embrace computer network security as part of the airworthiness design process. Until now, intrusion tests were not necessary because there was no physical connection--but as designers move forward with aircraft that require fewer people to fly, eventually things like in-flight entertainment will need to be controlled from within the cockpit. Further pilots may wish to use the in-flight wifi to receive updated navigation and weather products when available.

So if I were to comment I would suggest ways in which intrusion detection can be performed. Think of the FAA as a bunch of old pilots who are trying to figure out new technology; be kind, realize these are smart people, and help them learn how to perform intrusion testing.

Daniel • June 26, 2017 7:38 AM

The underlying problem resides in the inherent flaws of intellectual property which the digital age has thrust in our faces. I actually agree with Taylor Swift's insistence that artists deserve to be compensated for their work because that claim applies to authors, programmers, and anyone else whose work product is primarily intangible. The difficulty is that it is equivalent to claiming ownership in a gust of wind. When that wind could be packaged and sold in a physical item such as cassette or CD or hardback book the gustiness aspect could be cabined and thus minimized. In a digital age, however, the inherent fragility and slipperiness of the wind blows directly in our face; we feel how fragile that breeze is.

There is an old saying in DC that airlines get regulated by gravestones. That is going to be true, sadly, of airline software too. The first time a terrorist hijacks a plane by hacking the software we will see what the FAA has to say then. Let's be honest, the software is already so complex that professionally trained pilots get lost trying to use it properly (see AF 447) so the pilots may not even know anything is wrong until it is too late. And that doesn't even deal with the fact that fully automated passenger plans sans any human pilots are on the horizon,

Fundamentally the type of arguments the FAA is accepting are not deigned to enhance safety but to protect profit streams. However until we find better ways to compensate people for their work on open software people are going to keep making those arguments.

Brian Hunt • June 26, 2017 7:45 AM

Security through obscurity is an economic argument, not a technical security one.

In crypto-circles Kerckhoffs' principle governs, on the presumption that over a long enough period of time malicious economic resources are unlimited.

In reality, only vectors that are economically feasible will be attempted, being the lowest cost to achieve the desired outcome. It behooves the custodian of the processes to increase the cost and reduce the value of vectors.

Obscurity increases the difficulty and therefore cost, and a specific narrow purpose lowers the potential value, of establishing a vector. This could help make attacks economically unviable and for the lowest common denominator malicious rogue actor, psychologically prohibitive.

Which is all to say, it's a non-trivial analysis not based just on technical merit.

Given that common operating systems are routinely subject to vulnerabilities, and the economic substitution cost to apply those to an airplane OS would reduce to near-zero – and therefore potentially accessible to “script-kiddies”.

I personally believe the FAA perspective has merit — notwithstanding perhaps the FAA approving e.g. OpenBSD precisely for its security.

Not many people want to muck with airplane in the sky, but if it's as simple as repurposing a commonly available worm, it is almost certain to happen.

Frank Ch. Eigler • June 26, 2017 8:22 AM

@William Woody "most modern aircraft run two completely separate and physically disconnected systems [for aircraft safety & passenger entertainment]"

That's not really true. The entertainment systems are tied into navigation (so people can see maps), and PA (so people can hear important messages) at the very least.

ratchet freak • June 26, 2017 8:46 AM

Tha main thing that actually needs to happen is making sure that any output from the in-flight entertainment system cannot create an unsafe situation.

This means that any data interface between the entertainment system and the airplane flight system the must be secure. Preferably no data should ever flow from the entertainment to the flight system.

That will effectively sandbox the entertainment system. It's also relatively easy to implement in hardware.

After that the only issue is induced panic by hijacking the video/audio feeds. That's what the killswitch is for.

Wael • June 26, 2017 9:08 AM

They are talking about domain separations. Entertainment systems reside on a domain that's separate and isolated from cabin control and navigation systems. They say navigation and cabin control systems are typically proprietary, and highlight a couple of points about the advantages -- nothing wrong there, conceptually.

They're not basing this proposed rule on the argument that proprietary is more secure than "commercial" operating systems. Although what they say about limited exposure of proprietary "software" is true, additional considerations must be made: insider attacks, make sure the designer isn't able to compromise security because of additional internal knowledge of system details, and compensate for other weaknesses introduced by using proprietary over commercial. In other words, leverage the named advantages of proprietary and minimize its disadvantages through other design compensating methods. Easier said than done, but their arguments, as @Brian Hunt stated, do have merit.

Having merit is vastly different than having proven security, though!

William Woody • June 26, 2017 9:24 AM

@Frank Ch. Eigler: "That's not really true. The entertainment systems are tied into navigation (so people can see maps), and PA (so people can hear important messages) at the very least."

The PA hooks into the in-flight system in a similar way that a stereo system can mix audio signals: it's not a computer network connection but an audio wiring connection. And from what I understand, in-flight entertainment systems which provide your location on a map use a separate GPS receiver.

e1228 • June 26, 2017 10:52 AM

> Some systems installed on the Embraer Model ERJ 190-300 airplane will use operating systems that are widely used and commercially available from third-party software suppliers. The security vulnerabilities of these operating systems may be more widely known than are the vulnerabilities of proprietary operating systems that the avionics manufacturers currently use.

As I see it, FAA is being less "security-through-obscurity" than companies actually are.

albert • June 26, 2017 11:09 AM

@William,

"... Further pilots may wish to use the in-flight wifi to receive updated navigation and weather products when available...."

Pilots should not rely on -anything- accessible to the public by wifi. Passenger wifi needs to be totally isolated from FCS, from antenna to passenger.

It's not just a security issue. IIRC, a fire in the entertainment system brought down a plane. These systems are produced by vendors, not the aircraft manufacturers (who already have their hands full).

@Anyone,
Real time aircraft track has been available for a while. See: http://www.makeuseof.com/tag/top-5-airline-flight-tracking-websites/
If you haven't tried them, do so. You will be amazed.
The usual disclaimers apply.

.......
Software development is the ugly stepdaughter of manufacturing.

. .. . .. --- ....

Rhys • June 26, 2017 11:20 AM

Flight critical safety controls are under some regulations. Though this jeopardizes that compliance now for everyone else.

This will only facilitate a run to the bottom by competitors with long established, heavy investments in critical safety control systems.

I will start with a quote from John Rusbhy at the HCSS Aviation Safety Workshop, Oct 2006 “Because we cannot demonstrate how well we’ve done, we’ll show how hard we’ve tried".

Only now its "proprietary" so its a 'trade secret' that no 3rd party may assess or inspect. Gravestones will be the only measure of risk management.

This is just an end-run around the diligence, investment, and time resources to make reasonable and prudent efforts to protect the public. DO-178 will devolve to a self-certified check list at best. By technophobic accountants and CEOs who want mercurial rises to fame and fortune likening to Silicone Valley. on minor product innovations or differentiations. Furthering the growing mythology of a meritocracy.

NTSB will not be able to investigate the "proprietary" software for its rigor or development controls. Insurance will be an unenforceable contract when what is underwritten is now indiscernible, or exculpable.

The issues don't impact the flying public alone, Its also the "collateral damage" on the ground over which these vehicles will be given license to fly over.

The FAA sponsors have no proposed basic scan process- like the now deprecated DISA Gold. No method or means to establish even a floor upon which reasonable assurances are in place and are survivable under stressed conditions.

The common mode isolation issues discussed here (supra) are small to an increasingly weaponized consumer technology that demonstrates transverse mode injections, not just common mode.

Clive Robinson • June 26, 2017 11:23 AM

What is not at all clear is the underlying physicality or logical arrangements that is causing the aircraft supplier to ask for a variation to an existing approval.

All the document says is,

The Embraer Model ERJ 190-300 airplane design introduces the potential for access to the aircraft-control domain and airline-information-services domain by unauthorized persons through the passenger-information-services domain;

Which basicaly says not a lot, because the previous classification of the three domains.

Thus we have to think above the physical and logical layers to what effectivly is an information routing level.

The dangers at this level are the same as any Multiple Shannon Channel system with shared resources. Which is the same model for more conventional bridges, switches and routers.

That is,

1) CROSSTALK : Ensuring that information in one channel can not get into another channel.

2) SATURATION : Ensuring that no channel can prevent communications in the other channels.

Whilst these are a lot easier to achieve in Circuit Switched networks they can still be achived in Packet Switched networks.

Channel issolation to prevent cross talk is usually built into switches and similar that inject data from two or more data source channels into a common channel thus asside from error signalling this is usually not a problem.

The hidden problem is channel saturation under unusuall conditions.

The usual way of dealing with this is to supply excess bandwidth in the shared resource channel with some kind of rate control mechanism at the injection point (switch etc). Which often boils down to "drop packets and make the problem go up a layer or three in the stack", which in effect spreads the load out in time. Which whilst usially fine for data networks with transient loads where short term blocking / slowdown is acceptable, it is realy inappropriate for either Safety Critical (SC) or Real Time (RT) systems. Which unfortunately tend to be somewhat prevelant in complex systems such as Industrial Control Systems (ICS) and larger vessels and vehicles.

There is also another issue. Information from data sources injected from two or more channels into a common channel, often has to go to one or more data sinks. Whilst the common channel may have sufficient bandwidth it is unlikely that the data sinks will. Thus although the data sources are behaving within specification and the common channel is not saturated the data sink may well block and in the process inject error correction traffic back into the common channel causing an increase in traffic. It's easy to see such systems in real life in larger office networks PC's with 100baseT connectivity get switched onto a 1 or 10 Gig backbone which will happily deal with internal client to server traffic. However if all the PC users want to use VoIP at lunch time to speak to their partners/children the 10meg or less connection to the Internet gets blocked.

This is a danger with the aircraft systems that use satellite communications for all three domains.

Testing for such conditions is difficult at the best of times, and effectivly impossible when modeling with two or more hostile entities.

Which begs the question of what you are signing off on for the approvals...

albert • June 26, 2017 12:07 PM

@Ruys,

"...NTSB will not be able to investigate the "proprietary" software for its rigor or development controls...."

This need not be the case. There's no reason why the NTSB can't have NDAs with the vendors. The NTSB has a long history of competent and objective investigation.

As we found with Microsoft, there is no such thing as "proprietary" software. It's all out there, someware.

@William Woody,
Redundancy in FCS is so important that aircraft manufacturers would include it without being forced to do so. However, there is always the desire to combine systems to save weight(and $). The Internet lets us 'do everything' on one pipe. Of course this is naive. We are past the age of 'let the software handle it'.

I'm reminded of the saying, "Jack-of-all-trades, master of none". We can't afford this in the transportation sector.

. .. . .. --- ....

JohnnyS • June 26, 2017 12:23 PM

The problem with "security through obscurity" here is that once the first aircraft leaves the factory and is sold, no-one has any control over who will be seeing the software. It would be quite easy for a mechanic to loosen a board and put in a replacement, sending the old board with the software to whoever is paying them. Now the software is in the hands of a foreign state agency or a malicious group who can hire hackers to reverse engineer the software and work out an attack. That can then be delivered by malware or by a Richard Reid wannabe with a laptop or cellphone.

It is a fundamental axiom of security that physical possession of a system means that system is compromised: The ONLY way to design these systems is in accordance with Shannon's maxim, or you're just asking for headstones.

bear • June 26, 2017 1:11 PM

I was going to make a point but I note that Brian Hunt has already pointed it out.

Security-by-obscurity failed horribly (and will always fail horribly) in systems that are broadly deployed, where an attack if developed will be broadly applicable. Technical details known to enough people to develop a large complex system, cannot remain secret from people who want to attack that system, so the notion that something is proprietary will protect it as a secret when a broadly applicable attack on it is a cost-effective attack to develop is a fallacy.

A case can be made, however, for Security-by-obscurity as an economic argument. If they can reasonably argue that no one will bother develop an attack, because developing a more broadly applicable attack would be a more efficient use of the attacker's resources and expertise, that's an economic decision.

That's a tough call to make though when you're leaving the system essentially open. If an attacker can put in the work to attack an unprotected system once and then demand 3000 Bitcoins in extortion or ditch a passenger aircraft into the ocean, is that a less profitable use of the attacker's time than a more broadly-applicable attack on Windows boxes?

There's a lot of competition for windows boxes, and a lot of protection to get through, and what's there to get is starting to look like scorched earth. In the first place, you're likely to be locked out of windows boxes by somebody else's botnet. In the second place, if you get on them, you're likely to get nothing because by now they've either learned to back their hard drives up regularly or have nothing left on them that they're willing to pay a ransom for. In the third place you're likely to be detected because these days they have virus scans running. In the fourth place it's hard to spread in that environment because of malware filters in other windows machines and on the trunks at the email providers. Seriously, the plethora of broadly applicable attacks on Windows boxes makes developing a new attack on Windows boxes into a far less profitable use of an attacker's time.

So investing the effort in developing an attack on a relatively obscure system is sort of like spending the effort to move into a niche market; not much profit to be made there but if you're the only one in that market it's all yours, AND because of the lack of competition you get to charge a monopoly premium / attack entirely unprotected high-value systems.

bear • June 26, 2017 1:28 PM

@bear,

If William W. is correct (and I believe he is), those in-flight entertainment systems run Linux, as do thousands of IoT things. So there is already experience in hacking them out there.

As you said, aircraft are high-value targets.

. .. . .. --- ....

William Woody • June 26, 2017 2:16 PM

@uh, Mike: "Isn't this the FAA stomping on NTSB territory? The FAA is notorious for it's conflicted charter."

No. The FAA, the NTSB and NASA all have their fingers in the aviation pie. By and large the FAA establishes standards for airworthiness and the like, the NSTB investigates accidents and provides feedback, and NASA has some programs designed to help improve air safety.

(Source: I crashed my airplane on the 540 freeway in Raleigh about a year and change ago, so I got to see all of this in motion.)

ab praeceptis • June 26, 2017 2:28 PM

Funny how history repeats and certain tools from the sociology and psychology toolbox work over and over again, even in an "enlightened" society (haha, stupider than we ever were we consider ourself enlightened ...).

Yesteryears "masturbation makes you blind" reappears as "obscurity is not security" and even big names (like our valued host) fall for it.

Well, faa is *right* and obviously so. And not for 1 but for many reasons.

For a start, the O!=S (obscurity is not security) argument is plain false. In fact security (in our field) usually is professionally created high grade obscurity. Simple as that.

But even if we take the simplistic usual interpretation of O!=S it's wrong and should actually be "simple obscurity alone is not security".

Now, let's cut down on the faa matter. I posit that the "Pleiades 7" OS can not possibly be cracked. Simple reason: It doesn't exist, I just invented it. Now, before you laugh, make the next step: what's the difference between Pleiades 7 and, say, Oberon (for the sake of an example)? One is unknown because it doesn't exist and the other one is widely unknown because it (presumably) never found wide spread use. But you *could* inform yourself and get at the sources of Oberon. So let's replace Oberon by "Embraerix", the closed source proprietary OS.

How could you possibly attack an OS whose source you don't have, even whose binary you don't have? After all, besides some fuzzing which basically just finds points that are weak due to bad design or implementation (which we don't care about in this context) one needs to study and to gain some experience with a target.

Yes, sure, someone might break in at Embraer or an ultrarich customers son might grab the electronics of his fathers private jet and publish lots of material, etc.

But then security never was a 100% thing. What about the nsa having found a way to do factorization in low polynomial time? What about heartbleed?

The last question leads me to my final point for now. O!=S seems to imply - and is understand by many to mean i.a. that - that (f)oss is somehow magically more secure. Well, logic dictates otherwise in that proprietary not widely available software has the added security layer of being much less (or even not at all) studied.

Which is why I strongly suggest to reformulate the O!=S milkmaids weak rule at least to "simple obscurity *alone* is not security".

So, before continuing this whitchhunt we need to know more about the proprietary system/OS used by Embraer - which 99.9% of us can not do which again demonstrates the point.

The faa has a solid argument there. Not a complete one but a solid one.

David Leppik • June 26, 2017 3:33 PM

@ab praeceptis:

As long as someone has the binary code for the OS, and a state-level actor wants that code in order to develop an exploit, they will find it and make an exploit. From there, it's only a matter of time before the state-level actor loses their monopoly on that exploit.

Airplanes fly for decades. The time between NSA-proprietary exploit and script-kiddie hack is down to under a decade. It may get shorter.

That goes for your airplane, centrifuge, car, or light bulb. Being an obscure target doesn't help—so long as it's high-value.

ab praeceptis • June 26, 2017 3:58 PM

David Leppik

That's point *iff* one looks from a worst case assumption perspective. At the same time it's moot for more than one reason. One being that there is no 100% security; if that (if *somebody* ...) was the guiding rule, we might as well not care at all about security.

Usually the major problem in cases like that is that the application of common sense is treacherous. One must break it down cold-blooded logically.

- There is no such thing as 100% security. What we do - and should be aware of at all times - is minimizing risk, i.e. enhancing probability in our favour.

- the very intelligence agencies who should really know apply the principle of access limitation. "need to know", "compartmentalization", etc. are classical risk minimization mechanisms.

- It *is* of (often major) importance whether one has or has not and if yes, how much and deep, access to information, systems, etc.

Most of that could be reasonably called "professional simplistic obscurity". And again we note that obscurity *alone*, particularly simplistic one, is not sufficient but at the same time a valuable and well working layer of security.

And indeed that's what we observe at e.g. cia, nsa, etc. A multilevel, multipronged approach - incl. simplistic obscurity mechanisms.

Btw, there is - as in all wars - another often overlooked aspect, namely the investment/risk vs. gain/profit ratio. It is for that factor that the vast majority of malware, trojans, etc. are targetted at *widely used* systems. Simple reason: an attractive investment vs profit ratio.

The kind of attack that someone like Embraer has to look out for is quite different (I'm assuming here that they don't do utterly stupid things like flight control systems being reachable from entertainment systems or by wifi etc.). For that kind of attack an intimate knowledge of the target is largely indispensable - plus, importantly - the kind of players on the field will usually prefer simpler and cheaper attacks like a rubberhose attack or the plain old "here's some money (or a beautiful whore or ...).

Rhys • June 26, 2017 4:16 PM

@albert

An NDA is a negotiated document.

The understanding of open loop or closed loop controls systems has not been demonstrated by the entertainment OS's we have today. Nor do they advertise they use as appropriate for airworthiness life or safety critical applications.

And that gets to the core of an issue. Who assess, and with what criteria, the 'suitability of purpose' of the OS for the applications/missions it is to support. You know what the courts will say on liability claims.

Let's say the Embraer chose Android.

Alphabet makes no assertion or commitment to support any availability, or reliability number. Same for TPA (third party arbitration). Or for hot fail-forward/fail-back.

All the interfaces to the control surfaces and sensors must be written by a 3rd party. Drivers likely started, or containing, content from GitHub and the like will give one interface. The actuation systems will be another.

Saying that the code is proprietary is an ambiguous assertion, at best. The assembly might be proprietary, the code would be suspect- again, at best.

To provide a market window advantage, Embraer would likely use DevOps. As Android is. Which is fine for entertainment Apps, not for life critical or safety critical applications. Configuration control from suppliers, aircraft maintainers, and owners will be difficult, if not impossible to assure.

From flight to flight, a pilot would not have the same experience. How much time on the simulator will be required for Pilots to be take a plane and with what measures of assessment of the materiality of changes?

As for injection attacks, clock cycles and wait-states are both opportunities during normal operations, and when stressed operations exist. Fail safe is not an entertainment OS facility. Control systems have windows within which verification or validation of a command (or a state change) to be executed.

Last- this world we live in has evolved to where commandeering vehicles includes civilian aircraft when there is a flight control computer that takes suggestions from the pilot, not commands is another issue. Using passenger entrainment devices and radios that are more advanced than 1st generation ECM, ECCM, ECCCM devices is our reality.

Gweihir • June 26, 2017 4:36 PM

The interesting question is whether they have not talked to experts (because they mistakenly believe they are experts on this themselves) or whether they are ignoring clear expert advice.

Doing either is one of the customary preparations for arranging a really large disaster and, IMO, falls under gross negligence. This should cause personal criminal liability to all people that made and support this decision on their side.

Ken • June 26, 2017 4:47 PM

The Embraer E-Series of planes use Honeywell's Primus Epic avionics systems for the aircraft control domain. (This new plane is using Primus Epic 2 - I was one of the architects of the original Primus Epic oh so many years ago now...)

The Operating System in that architecture was originally purpose built by Honeywell as a joint effort between Honeywell's Business and Commuter Avionics Systems division and Honeywell Labs. It was called the Digital Engine Operating System (DEOS) and was later sold to DDC-I who still markets it.

That said, as noted above the real special conditions are at the bottom of the notice. Item 1 being the particularly important part:

The applicant must ensure that the airplane design provides isolation from, or airplane electronic-system security protection against, access by unauthorized sources internal to the airplane. The design must prevent inadvertent and malicious changes to, and all adverse impacts upon, airplane equipment, systems, networks, or other assets required for safe flight and operations.

The concern is whether the statement in the Federal Register implies the FAA is amenable to arguments in the risk analysis that support security by obscurity?

Max • June 26, 2017 5:17 PM

Perfection is not an option. All complex system are insecure. The question is whether the insecurities will be exploited or not. Depends of payoff and cost of developing the exploit. Obscurity can be a hugely important factor, yes? So why say "security through obscurity" like it's a bad thing?

Rhys • June 26, 2017 7:30 PM

@Max

Logical argument is flawed. And some assertions are also erroneous.

Return on investment gets to thinking such as Ford's Pinto.

Death benefit is cheaper than recall and relocating the gas tank. Modifications which leave survivors only increases liability payments and benefits vs fixed death benefit cost. Best for stockholders to do nothing.

In infosec, it is also the logic which invites the belief in a solution that isn't.

If a company markets a product with the intent that it will be obscure, the components would also inherit obscurity. If the product is successful, its obscurity will diminish with popularity. And time. Who makes such a product to be unsuccessful, obscure in the market?

Most airworthy certificates are several decades or more. Obscurity won't last long. Even some of the sub assemblies underneath might also become popular even if the vehicle doesn't.

And it also assumes most attackers have a rational expectation which regulates their behavior. Which is also a false assumption.

65535 • June 26, 2017 9:47 PM

“…readers will immediately recognize the "security by obscurity" argument. Its main problem is that it's fragile. The information is likely less obscure than you think, and even if it is truly obscure, once it's published you've just lost all your security.” –Bruce S.

I agree.

I suspect that clever K street PR firms are at work and those with Embraer are doing their gig well. I would also guess other aircraft manufactures who do separate critical flight control systems from entertainment systems are not happy with the FAA and probably applying pressure on the other side.

See FAA link down page about 60 percent:

“…aircraft-control domain consists of the airplane electronic systems, equipment, instruments, networks, servers, software and hardware components, databases, etc., which are part of the type design of the airplane and are installed in the airplane to enable the safe operation of the airplane. These can also be referred to as flight-safety-related systems, and include flight controls, communication, display, monitoring, navigation… The operator-information domain generally consists of functions that the airplane operator manages or controls, such as administrative functions and cabin-support functions.The passenger-entertainment domain consists of all functions required to provide the passengers with information and entertainment systems.”

“…The Embraer Model ERJ 190-300 airplane design introduces the potential for access to the aircraft-control domain and airline-information-services domain by unauthorized persons through the passenger-information-services domain; and the security vulnerabilities related to the introduction of viruses, worms, user mistakes, and intentional sabotage of airplane networks, systems, and databases… For electronic systems-and-assets security in these domains, the level of protection provided against security threats should be based on a security-risk assessment, noting that the level of protection could differ between domains and within domains, depending on the security threat…the operating systems for current airplane systems are usually and historically proprietary. Therefore, they are not as susceptible to corruption from worms, viruses, and other malicious actions as are more-widely used commercial operating systems, such as Microsoft Windows, because access to the design details of these proprietary operating systems is limited to the system developer and airplane integrator” –FAA

https://www.federalregister.gov/documents/2017/06/14/2017-12281/special-conditions-embraer-sa-model-erj-190-300-airplane-electronic-system-security-protection-from

Well, I hope Embraer has a good Anti-virus software bundle. They will need it. /

Oox7aeki • June 27, 2017 2:43 AM

Did y'all see http://fc17.ifca.ai/preproceedings/paper_17.pdf - in which aircraft ground-to-air communications (for certain planes) turns out to be secured by comedically bad proprietary crypto? A good example of security-by-obscurity failing, since the paper's authors had no real difficulty in breaking it despite not having a published description to work from.

Clive Robinson • June 27, 2017 3:16 AM

@ Oox7aeki,

in which aircraft ground-to-air communications ... turns out to be secured by comedically bad proprietary crypto

I stopped reading with a groan at the words "mono alphabetic substitution cipher" in the introduction.

Mind you Microsoft used to use such a cipher in various places in their OS's.

Quercus • June 27, 2017 9:58 AM

There's a difference between 'security by obscurity' and 'security by diversity', and there is some merit to the second. Running an unusual OS won't offer any protection against a targeted attack (and is probably worse than Linux or Windows, as there are fewer security researchers pointing out holes to patch), but it will help against untargeted worm/virus-like malware that tries to spread indiscriminately. The botnet/ransomeware-of-the-week will probably not get a foodhold on DEOS even if it was somehow exposed, and that is a real security benefit.

Again, you're giving up a lot of security against targeted attacks by having fewer white-hats picking apart your code, but you are gaining resistance to untargeted attacks.

albert • June 27, 2017 10:30 AM

@Guys,

Don't overthink the issue. All that is necessary to control the aircraft is to gain entry to the FCS as a 'legitimate' user. I'm assuming that the entertainment system (ES) is totally separate from the FCS. If it isn't, then we'll have to call our old friend, Al Betzerof.

Sidenote: Regarding the display of flight data to passengers. Is there such a thing as truly one-way communication? A data diode?

. .. . .. --- ....

Wael • June 27, 2017 11:34 AM

@albert,

Is there such a thing as truly one-way communication? A data diode?

Doesn't UDP come close? Connectionless, no control signals... What if flight data is "streamed" ?

Rhys • June 27, 2017 1:54 PM

@albert

Yes, there are data diodes. Few commercially marketed. The solution set is cross-domiain communications.

Here's one: https://www.owlcyberdefense.com/about-data-diodes.

Here's another: http://www.lockheedmartin.com/content/dam/lockheed/data/isgs/documents/TMAN%20Brochure.pdf

It isn't just installed first cost that keeps many commercial owners for integrating. Its the life-cycle cost. And it is not a complete solution.

These network data diodes are common-mode solutions, however. Not transverse mode.

The host has to be not just hardened but, also have protection on its internal buses prior to the NIC or HBA cards/daughterboards.

Software defined radio, like any other tool, is useful to other purposes than the one a retailer may embed.

ab praeceptis • June 27, 2017 2:21 PM

Quercus

"as there are fewer security researchers pointing out holes to patch"

That's one major point you seem to have gotten wrong.

I had just a relatively short look at DEOS but (besides the usual corp. marketing BS) what I saw wasn't bad at all and strongly suggests that DEOS was designed and implemented by good engineers and that (real) safety and security was high up on their list.

So, a) one should be careful referring to "1000 eyes" as, in fact, the openssl crown jewels failed to get even 4 *qualified* eyes looking at it. b) one must keep the relations in mind - plus - one must understand them.

Explanation: Even a first uneducated approach clearly shows that one needs many more "security researchers" (of, uhm ... diverse quality ...) for a 10 mio loc projekt than for a 100 kloc project.
So, when comparing wide spread OSs like linux and niche OSs one must, at the very minimum, look at the "security researcher" per loc ratio. I doubt that Linux offers a better ratio than DEOS.

Furthermore and importantly, one can *not* go by the a.m. ratio because of the quantity - complexity relation. To put it in a simple way: to examine 100 loc is a *very much* different task than examining 100 kloc because the complexity doesn't grow in a liner but rather in an exponential way.
The same, btw. is true for the design phase.

Basically this comes down to saying that a small OS can be made secure but a large one can not. Add to that the *very important* factor of DEOS having been designed with safety/security in mind while linux hasn't been designed at all and certainly not with safety/security in mind. And then add the burden of verifying an existing code body.

You will find that the result is linux, windows, etc looking *very* bad in comparison.

Rhys • June 27, 2017 3:13 PM

@ ab preaceptis

I don't know its quite that simple.

An OS with DO-178B credentials is just a place to start. Speculation on my part but, this is to dodge the cost of 178C issues when the plane was ready for market and 178C would add 18 months to their timeline.

Nothing for, or against, the OS. Only that no Manufacturer's business market windows should co-opt configured item development & assessment to accommodate unfortunate program development schedule and forecast management.

The OS isn't just PnP (plug-and-play). Many control subsystems, devices, and sensors on the aircraft require some custom integration. By the integrator. With or without consult of the individual suppliers.

CLOCs, KLOCs- haven't heard those measures since assembler and Cobol days. Complexity is better assessed in feature points, function points, story points...etc. Caetaris Paribus does not apply to all the languages, compilers, and assemblers available on the smorgasbord to aircraft designers.

Here' s a marketing tear sheet on DEOS which might be helpful to others. W/O regard as whether it is used in this vehicle now, or in the near future.

http://www.businesswire.com/news/home/20110407005543/en/DDC-I’s-Deos-RTOS-Selected-COMAC-C919-Commercial

Here's the 2017 Market for FCS/FMS: https://techannouncer.com/global-aircraft-flight-control-system-afcs-market-2017-bae-systems-honeywell-moog-rockwell-collins-sagem/

Although a few are built on WindRiver's VXworx, too.

The exemption being sought appears to have no constraints to only purpose built OSs, however. And I remain circumspect about the current FAA leadership's knowledge about the difference between Tuxedo and an RTOS.

ab praeceptis • June 27, 2017 4:04 PM

Rhys

My point was not "DEOS is great!" (or safe or whatever). My point was to question the suggestion that "oh so many security researchers" looking into linux, windows, etc is true, relevant, and helpful.

I know what I'm talking about as I know both sides (safety in mind design vs post factum inspection) and have concrete experience with both.

It's very hard to quantify it or to even come up with reasonable algorithms but it's safe to say that post factum inspection is exponentially harder, particularly with C/C++.

The other major factor is loc. Granted, loc is a rather crude ruler to make statements about complexity but a) it isn't helpful to *very considerably* increase the complexity of this matter (here), b) loc (lines of code) is widely understood, and c) the difference between probands (e.g. linux vs DEOS) is usually of a magnitude that even crude measuring gives roughly correct results when talking about tens of millions of loc vs. tens or hundreds of thousands.

Finally there are also factors involved that are hard to quantify. An example would be "OpenBSD devs try hard to be on the safe side" vs "linus never gave a rats a** about safety". Hard to quantify, yet immensely relevant.

But let's keep our focus on the most relevant point: safe by design *is* feasible while safe per aftertought isn't.

Hence my point wasn't do 178 x vs y. I don't care a lot about golden stickers (unless Thoth made them for a beautiful card). Basically I take do 178 or eal etc to mean "safety was at least of some concern" and probably even some formal standards were in place.

Ken • June 27, 2017 9:12 PM

Yes, DEOS was developed with safety in mind, and much (formal) analysis. DEOS is actually pretty great, IMHO...

Some references:

Scheduling:
A robust high-performance time partitioning algorithm: the digital engine operating system (DEOS) approach

On the formal proofs for DEOS properties:

Verification of Time Partitioning in the DEOS Scheduler Kernel


Using Model Checking for Verification of Partitioning Properties in Integrated Modular Avionics

On the overall Primus Epic architecture - DEOS is the OS for the processors, but Epic is an aircraft-wide integrated system:

An Epic Tale: A look at an integrated avionics system
(I have patents on the Virtual Backplane Network)

http://www.helicoptermaintenancemagazine.com/article/avionics-system-epic-proportions-part-one-two
An Avionics System of EPIC Proportions - Part one of two

WhiskersInMenlo • June 28, 2017 12:17 AM

This is more interesting than just this one fly by wire aircraft.

The same issue set applies to modern automobiles now and in the future.

The economics of a $50,000 auto are not the same as a million dollar aircraft with 94-114 passengers.

Security by obscurity is subject to industrial espionage domestic and international and might best be pondered in the context of software blobs (nVidia) for graphics, coprocessors, security modules (inside Intel CPUs), and IP silicon functional blocks built into SOC chips and more.

Autos can be rendered stopped by lo-jack should loan payments fall in arrears. Hacks have shown other vulnerabilities. Phone updates are non existent after 24 months by many vendors (Apple seems to be a good guy here).

We are seeing more and more company system attacks in the news. Some hold the company hostage. Cyber tools have been deployed as an adjunct to armed conflict.

TLAs sit on known flaws and demonstrate another class of false security by obscurity.

A recent discussion on Microsoft recent patches for very old software points out the scope of the issue. One detail lost in the Win10 free update was hardware vendors had to submit their BIOS and more for feature testing. Some quite new hardware did not update while some older did (hardware vendor choice, this one I know was sold and the brand recycled I think leaving it an orphan). So some Win7 hardware is newer than other Win10 hardware and will fall of the end.

Linux runs well but NDA and for some closed hardware security by obscurity applies.

International?

That takes us to the anchor... what rules for BIOS updates exist.
Is any of that open to inspection?

Rhys • June 28, 2017 1:24 PM

The issue is "proprietary".

Not 'a' product. Not 'a' category of product. A domain of "proprietary". As a 'rule'.

Criteria and weightings would be unknown and unassailable. Best practice and state of the art will be unknown or speculative.

There is a trade off between the public's interests and the owner/developer's interests. Copyrights, patents, and performance rights are intellectual property protections that are a balance of those interests- public & private.

Equivocating trade secrets (proprietary), obscurity, and secrecy are what is the proposition. Not any individual product. Might as well be talking about the joey-bagga-donuts OS. FAA is to make a rule. Not for any one product alone.

As I previously stated, it is not the just flying public and aircraft manufacturers that have a stake. Its the collateral damage on the ground that is also the public's interest. A much larger stake. By magnitudes.

Not one article here, or supplied to the FAA addresses more than just cyber security issues. OPSec of the developer is nearly nonexistent in the development process. The sources of code (let alone code inspection) is not, nor was not, a consideration. As were the libraries and tool sets controls. Employee hiring & turnover rates only further erode obscurity. The assessment process, once, was to distill out the impurities that might have entered the development.

The FAA leadership is talking about instant displacing an entire infrastructure evolved over 70+ years. Rebaseline won't make US competitive. No matter how bucolic the memories of the 1960's might be.

Jan • June 29, 2017 2:42 AM

Related to this topic.... what do you guys think of datalink (CPDLC) via internet ?

I mean, sending ATC clearances via https connection to a 'mobile' device in the cockpit, as an add-on for voice comms...

This mobile device could be a tablet / smart-phone ... E-flight bag ... not connected to the Avionics of course...

Surely, the airframe needs to be equiped with broadband internet... but that will become mainstream on request of the PAX in the near future ...

Interesting to get some thoughts / comments...


Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

← Friday Squid Blogging: Injured Giant Squid Video Separating the Paranoid from the Hacked →

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of IBM Resilient.