Software Increases 
Unmanned Craft Survivability

The U.S. Defense Advanced Research Projects Agency is developing new control software to reduce the vulnerability of unmanned systems to cyber attack. This effort is relying on new methods of software development that would eliminate many of the problems inherent in generating high-assurance software.

Unmanned vehicles suffer from the same vulnerabilities as other networked information systems. But, in addition to their data being co-opted, unmanned systems can be purloined if adversaries seize control of them. This problem also applies to human-crewed systems with computer-controlled components.

If the research program is successful, then unmanned vehicles will be less likely to be taken over by an enemy. Warfighters could trust that the unmanned vehicle on which they are relying will not abandon its mission or become a digital turncoat.

This security would extend to other vulnerable systems as well. Networked platforms and entities ranging from automobiles to supervisory control and data acquisition (SCADA) systems could benefit from the research. The vulnerability of SCADA systems is well-established, but only recently has research shown that automobiles can be co-opted through their computer-controlled systems. The program’s goal is to produce high-assurance software for military unmanned vehicles and then enable its transfer to industry for commercial uses.

The Defense Advanced Research Projects Agency (DARPA) program is known as High-Assurance Cyber Military Systems, or HACMS. Kathleen Fisher, HACMS program manager, says the program is aiming to produce software that is “functionally correct and satisfying safety and security policies.

“It’s not just that you’re proving the absence of a particular bad property from the security perspective,” she explains. “You’re actually positively proving that the software has the correct behavior.”

Fisher points out that with unmanned systems, an attacker can reach the relevant software remotely. Until a few years ago, cyber-physical systems such as automobiles had their own built-in security because they were not networked. But, automobiles increasingly are likely to have network connections, especially those that automatically provide for emergency response in the event of an accident. “The fact that pretty much all of these systems are networked means that the kind of vulnerabilities we’ve seen on desktop and traditional computing systems for the past 20 to 30 years now carry over directly to these kinds of cyber-physical systems, such as vehicles,” she says.

Yet, that threat can be greater than the one inherent in computers. These physical systems are connected kinetically to the real world, so attackers can pose problems far beyond the cyber domain. The vulnerabilities may be the same, but the potential damage is far greater, Fisher points out.

HACMS began in August 2012, and it is slated to run in three 18-month phases. Each phase will end with a penetration testing assessment, along with a demonstration of the tools that were developed and the high-assurance functionality. The program goal is to increase the amount of software that can be replaced in each phase, Fisher says.

Researchers are divided into two groups: an air vehicle group and a ground vehicle group. The air group is organized under Rockwell Collins as prime. Subcontractors include Boeing, National Information and Communications Technology Australia (NICTA), Galois and the University of Minnesota.

The ground team was assembled by DARPA from bidders for individual elements. They include SRI; Hughes Research Laboratory and General Motors; Kestrel; Carnegie Mellon University; the University of Pennsylvania; and Princeton along with Yale and the Massachusetts Institute of Technology.

Government participants include the U.S. Air Force; the U.S. Army Tank, Automotive Research, Development and Engineering Center (TARDEC); and the Department of Transportation.

Fisher explains that the program is working with four target platforms. The four vehicles were chosen to maximize the results of the research, but they share the common characteristic of potential vulnerability. Before developers began to work on new code for them, each vehicle was subjected to a red team software assault. Fisher reports that a penetration and testing team led by Draper Laboratories was able to take over all four vehicles. The team spent a total of one month on each vehicle, which is “not a particularly significant level of effort,” she adds.

Researchers are responsible for ripping out existing code from these vehicles and replacing it with the program’s product. The red team has completed early penetration exercises on all four vehicles, she notes, and that step is repeated on the code that others have produced at the end of each phase. Over time, this should increase the difficulty for red teams to break into each system.

One target platform is an ArduCopter, which Fisher describes as a hobbyist unmanned aerial vehicle. The code in this relatively small system is readily available, so developers should be able to replace the code completely. Developers already have built a domain-specific language called Ivory that would generate flight control types of code. Half of the original control system code has been replaced by the new high-assurance version—enough that the helicopter can be flown using this new code, she posits.

This effort is paired with a helicopter being produced by Boeing that can be manned or unmanned, so the ArduCopter’s architecture is being adjusted to match that of the Boeing helicopter. This will allow for easy transfer of the software developed for the ArduCopter to the Boeing craft. Fisher points out that the Boeing helicopter effort does have specific software replacement goals for each phase, unlike the other vehicles.

The other two target platforms are ground vehicles. One is the Black-I Robotics LandShark unmanned ground vehicle, which is used mostly for border patrol and mine-clearing exercises. Fisher notes that it is an open-source platform in which researchers can access all of its source code.

The other platform is a U.S.-built automobile that offers similar aspects to the LandShark. Fisher explains recent studies have shown that cars are extremely vulnerable to software attacks. On average, a modern car has 3,200 embedded control units connected via a network accessible by a port under the steering wheel. One study pointed out that an intruder connecting to that network could reprogram all the computers on the car, which would allow the intruder to take over all the vehicle’s functionality—brakes, steering and virtually all control functions. This effect could be achieved by accessing the network remotely through four different vectors, she says.

The program is taking three different approaches toward achieving its goal. One approach entails program synthesis, in which an engineer writes a high-level specification of a desired behavior instead of just writing program code. A computer converts this specification into the program code along with proof that the code implements the specification correctly.

Another approach involves domain-specific languages that are focused narrowly on specific tasks. This type of language provides more support to the programmer, so engineers are developing domain-specific languages for building high-assurance vehicles and then using the results to generate the implementation and proof of correct behavior. A third approach uses automated theorem proving to prove the efficacy of the code concurrent with it being written by developers.

The research is being conducted in two different domains, Fisher relates. One is operating system code, but this is relatively simple because most unmanned vehicle operating systems employ thousands of lines of code instead of millions of lines for traditional desktop operating systems. The other domain is control systems, which tie together sensors and control actuators. Both types of code have abstractions that allow developers to write the desired behavior concisely, she notes.

“We’re really pushing the state of the art in terms of what we know how to do,” Fisher says. “Because we’re being so aggressive about that, we’ve given up trying to verify legacy code. We’re focusing on producing new code and verifying that.”

Scaling the software development is a major challenge, Fisher says. Producing high-assurance software entails meeting a more stringent requirement than just writing code. One way of achieving this is to increase the level of automation and lower the level of expertise and time needed to generate it.

Fisher describes another challenge as compositionality. Combining two high-assurance components into a high-assurance composite—without redoing all the assurance arguments—is difficult, she observes, but necessary to achieve the program’s goal. “Compositionality is the only way to build large systems,” she states.