That was some of the best flying I've seen to date, right up to the part where you got hacked US defence firm Raytheon is punting a security suite that apparently promises to harden military aircraft against "cyber anomalies". The company is reportedly developing "a new warning system that tells pilots when their planes are being hacked". "Basically, we're trying to give the pilot the information about what's …
No. A parallel bus sends the bits of a data byte/words in parallel at the same time over seperate physical wires in the connector. Which sounds like a great idea and it is - up to a certain length. Then slight differences in the makeup of each individual wire means that the bit signals all travel at slightly different speeds start getting out of sync with each other and after only a few 10s of metres it stops working altogether. Which is why serial buses took over.
It does raise the question - at what point do you consider things to be parallel.
Obviously if the various lanes are entirely independent (supplying different cards etc) then they're not a parallel bus.
but I assume that GFX cards still split their data down the lanes - they won't do it bit-wise, but does byte-wise not count as parallel? What about MBwise...
Maybe the definition should be based on the result of one path failing - I imagine a GFX card would cope with 4 rather than 8 lanes, even if can't transition live.
A printer cable with half the 'lanes' gone would of course be useless...
It has a lot more in common with twisted pair ethernet than it does with RS232 in that data is sent as packets over a wire and these paclkets are encoded/decoded by hardware into frame buffers before being pushed further up the stack. Its a lot more complex than just setting the DTR line to +/-5V and reading raw binary data off the wire as per old style serial buses and there's probably some hidden attack vectors in various USB implementations if anyone bothered to look (and I'm sure someone has);.
USB literally stands for Universal SERIAL Bus.. It's literally in it's name that data is sent one bit at a time down the wire - the definition of a serial data bus.
That the data is encoded deferentially is an implementation detail for safe transmission rather than changing that the bus is serial vs parallel.
If it were parallel then multiple bits of the same byte would be sent over the wire at the same time by the same clock signal - but they aren't.
Hang on, I'll just ask my Dad - on the off-chance he might remember. He used to service them in the early '60s...
.
... mind you, wiki has them "Retired from military service 2014" (!), so probably you need a more recent aircraft engineer :-)
It's not even vaguely implausible! Sorry, El Reg, you're out of your depth here!
The Hunter T.8M had a Blue Fox RADAR. The Blue Fox had 1553. Therefore the Hunter T.8M had 1553!
Also... Singapore upgraded their Hunters in the late 1970s. The upgraded Hunters could carry AIM-9 Sidewinders, and given that timescale, the missiles would have been AIM-9L variants, which use 1553 to connect to the host aircraft (e.g. to report status back, initiate self-test, light the blue touch paper...) Therefore Singapore's upgrades in the late 70's would have included MIL-STD-1553.
(And why would you not? 1553 is a very simple, 1mbit/sec fault-resilient bus running over relatively cheap cabling. Easier to use that -- with it's plethora of support and development tools -- than try to invent your own!)
On the ground, the M1 Abrams has 1553 bus. The M2/M3 Bradley probably does also.
Stryker and most more-recent mobile ground platforms have eschewed it for Ethernet and CAN (SAE J1939 compatible).
Ah, sweet memories. A montage of hand gestures, working men, hardware and lustful flying weapons of war, peeking through steam backlit by a setting sun, the monochrome a raw sensuous orange with dark sillhouettes and a gentle guitar crescendo that built the pace, the tension, the raw power about to take to the skies, released with a switch to joyful fast paced lyrics and.. the rest of the film wasn't bad either.
Their marketing spiel is just that - pure marketing. The whole 'cyber anomaly' bit is one big clue.
And even allowing for the unlikely scenario of their demo what exactly are they proposing? Message filtering for incoming data transmissions? Already happens, mostly by just binning everything not expected & forcing strict formatting. Protecting the RTOS running in a box? Can already be done, not really needed most of the time. Filtering the databus? If it's an expected message with spoofed data you won't know the difference - plus it may well just clash with the 'real' data from the proper source if you're just injecting - and if it's an unexpected message it'll just be binned. Just like data that deviates too much is usually just binned - more often than not to get unusual things successfully injected you have to start forcing values straight into process memory.
I can sort of see why they went with 1553/429 as a target as it's a simple old thing which is why it drifted of to the peripheries. Try that stuff with the newer things like AFDX and you'd trip up much more quickly.
That's not to say you can't make avionics dance to any tune you want with knowledge and effort but it isn't trivial, it's extremely specialist as a skill and it certainly isn't something you can do as a remote 'hack'. Even with physical access you'll usually only win by rehosting and poking things in ways the original platform just can't do.
Though I'm sure none of this will get in the way of selling something unnecessary that doesn't really do anything useful. It works well enough for the PC & phones markets so they may as well try the same game for aircraft.
If you could get a bad actor to physically insert a node onto the AFDX bus. That node then learns the communications protocol, MAC addresses, etc. Then you might be able to packet inject some bad data.
But, the AFDX switch should spot the change in network topology using its TDR cable length/impedance checks and flag that up as an error. And secondly aircraft communications are usually very time bounded, so you would have to mask the original signal with your own, at transmission time and without collision detection systems noticing it.
1553 is a little easier, but even then it's non-trivial, and probably at state-sponsored level of ability.
Much the easiest attack vector is a missile if you just want rid of a target.
Dodgy (manipulated physically or in the signal conditioning) sensors in the after sales market would be the easiest long game if you want deniable responsibility and didn't mind a scatter-gun approach. For example, implementing slightly bad data on a set time/date e.g. all speed indicators showing a speed reducing by 1 knot per second starting at 12:00 on 10/10/2025 (if the majority of the after-sales sensors agree, the systems will have to accept it as real data.) As always, it's those who would cut corners who would bring the whole system down!
[You can freely have that as the plot to your next novel!]
Article: "The firm also says the system can be modded for automotive-grade CAN buses.
"Another marketing feature mentions a highly specific use case: 'Operational threats that can come either from an enemy or from a US soldier inadvertently causing a cyber intrusion to propagate by plugging his malware-infected cell phone into a USB port on a Stryker vehicle, for example.' "
First off, CAN is much more dangerous than 1553. I should know, but I can't comment further.
Second, Stryker's USB is not a big issue. But I can't comment further on that either.
Third, Stryker uses CAN bus for various things. But I certainly can't comment any further on that.
But given all that I know (and can't talk about), I envisioned that a CAN bus monitoring system to weed out unintended traffic would be a cyber necessity for future mobile ground platforms. But I can't tell you more about that either.
(Of course, if you wanted to be crude and already have physical access, just start cutting wires instead. Power, CAN, Ethernet, everything = dead tank. Knowing the best cables to snip may be restricted but not classified.)
Meh - knowing just how sensitive aircraft are(n't) I listened to end of the rubgy last week - took until we were at about 1-2k feet (guesstimate from looking out of window)
Then I dropped the mobile signal (because at speed and altitude your device will spend more battery and time than is healthy looking for appropriate towers).
Heck a few months ago I completely forgot that my tablet connection was online, and it was just sat in an overhead bin for the whole flight...
OTOH I do appreciate the experience of not having "I can't hear you I'm on the plane" being shouted at some poor soul who probably could hear the person speaking quite well, until they got deafened.
Shoudl we ban such connections on trains as well?
I think the data connection is too useful to lose there, but what do I know.
What the hell is a combat helicopter doing with wireless receivers ? Even if I can accept that they may have a use when on base, shouldn't they be shut down when in flight ? Isn't that something that could enable their detection ?
Even if not, I highly doubt that a combat helicopter is broadcasting anything that a wireless receiver could have a use for. There is undoubtedly a (shielded) wired data bus between all elements that need it. Any wireless receiver should be shut down when in flight, that would end the problem.
No expert but it's probably some "connected battlefield" stuff, sharing telemetry, radar contacts, troop/vehicle movements etc. to and from other theatre assets. Plus helo's aren't exactly stealthy; audible and thermal emissions are really hard to mask, detection based on RF emmissions seems low on the list of detactability concerns.
Late comment: what they're doing is maintenance reporting. The vehicle lands, spots the WiFi signal, sends it's status, and then the maintenance crew knows what knobs to turn / liquids to top up. Key benefit is reducing the number of personnel wandering around near spinning rotors.
Easy to add interlocks so the WiFi kit only comes on when there's weight-on-wheels!
"a new warning system that tells pilots when their planes are being hacked"
Why not harden it so it greatly reduces the chance of hacking? This sounds like a feature that hackers will just shut off. Still, may be handy in the cases where your planes are sold to foreign governments.
If the aircraft is behaving oddly, a trained pilot would just shake the stick to disconnect the autopilot, and then fly level until the problem has been isolated, and if that can't be accomplished, just switching off affected avionics. That's kind of the point of having two separated avionics suites in the cockpit anyway: You have your big fancy glass with all your interconnected systems goo-gaws; but then you also have your extremely simplified and isolated backup systems that lack anything that can be 'hacked', usually mechanical; sometimes self-contained glass with a dedicated pitot and embedded GPS attached to a dedicated backup battery and is usually accompanied with a switch to disconnect it from the aircraft's power buses.
The critical flight systems, like stick inputs, trim controls, throttle, etc are going to be using ridiculously simple analog signaling on multiple redundant channels. Fly-by-wire systems, at least the ones I've looked at, are nothing more than a couple channels of analog differential pairs attached to linear potentiometers on the L/R control linkage with some optoisolators to allow disabling malfunctioning channels and to bump the signaling to +/- 28 V, and made some transistors to mix in auto-pilot control if the A/P isn't just operated by servos attached to the linkages to move the controls physically. These signals wind through the aircraft to hydraulic servos that manipulate the actual control surfaces. Same story with trim, flaps, and most throttle systems.
Really, the most damage you can do to an airliner is annoy the hell out of the pilot that now has to hand-fly the plane to a diversionary airport.
I would imagine that something carrying munitions would be equipped with something at least as reliable and have better trained pilots, especially since the military is where Murphy's Law not only originated, it is proven daily.
A few points about aircraft networks:
ARINC-429 is a serial communication bus where there is a single sender and one or more receivers on a "bus". This is hard-wired, so if you need to have bidirectional communication between two subsystems, there must be two buses, one in each direction. A typical ARINC-429 installation has many buses, each requiring their own conductors, and the mesh of wires running around the airframe can be quite complex, take a long time to repair damaged cable runs, and quite heavy.
MIL-STD-1553 is a multi-drop base-band half-duplex multiplex serial data bus where every node capable of sending messages on the bus uses the same media in a TDMA sort of way. Fewer cables are required, so it's lighter and easier to maintain/repair. It was codified as a Military standard around 1972. It is a master/slave bus, Nodes on the bus are referred to as Terminals, and the terminals are connected to subsystems (they may be embedded within the subsystem or connected via some other means). The slave terminals are referred to as "Remote Terminals" (or "RT"s) and these cannot send data over the bus unless they have received a command addressed to them from the master, called a "Bus Controller", or "BC". Only a single BC can be active on a MIL-STD-1553 bus. Though the standard itself allows for a BC to hand off control to an RT allowing it to take over as the BC, this is not done in military avionics. If someone somehow introduced an RT on the network, the BC has to be programmed to issue commands to it or all it can do is eavesdrop on the traffic acting as a Monitor Terminal. Adding a BC would become very noticeable very quickly, as the real BC would not be expecting the responses it sees on the bus. Most MIL-STD-1553 networks are multiply redundant (usually 2, but can be more than that), and the BC has to be connected to all of the channels. Your typical fighter has several disjoint 1553 networks, each with a specific purpose. I'm not aware of any airframes that use MIL-STD-1553 to control the flight surfaces or engines.
The "AFDX" (ARINC 664) networks used on commercial airplanes use what's called "profiled Ethernet", and the Ethernet switches used in the network are configured, on the ground, to only repeat frames from specific MAC addresses from one side to the other. There are multiple paths between nodes on the network, and the AFDX specific "end-system" compares data received from different paths and will only accept frames that meet certain criteria. Discrepancies between data received over different paths are reported up to the software and stored in an audit log. Your stock Ethernet card will not be able to talk on the network, and it takes a deep knowledge of the network configuration loaded on the aircraft to inject data and commands onto the network and have them accepted by the systems.
Overall, I think the chance of someone attaching to either type of bus while the aircraft is in-flight is quite low. If the attacker has enough access to make it work, they have enough access to inject their modification into the operational flight software loaded onto the airplane while it's on the ground, which removes the need for physically compromising the control and sensor networks. Denial of service can be quite damaging, but I believe that that is the highest risk to the safety that in-flight hacking presents. On the ground hacking is another matter, and if the attacker is able to modify the operational profile of the aircraft, there's not much to prevent that from being exploited. This does not address collecting sensitive data from the aircraft controls and sensors, but in most cases would prevent the hacker from controlling the vital flight systems.
I think what Raytheon is offering is a way to protect the subsystems from hacking via control channels that are not part of the on-board data buses, though they may also monitor what's going on over the data buses to detect unexpected messages. Its primarily the datalinks, not the control and sensor buses, that might be vulnerable - if you can manage to exploit a weakness in those, a remote attack is possible that does not require prior physical access to the plane.
Disclaimer: I work for a company that is in the avionics and communications business. I do not at this time work for Raytheon or any of its subsidiaries, and have not done so in the past. I speak for myself, not for my employer.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
