Numerical Analysis of Cyberattacks

Unmanned aerial systems (UASs) have taken on a very large role in military operations and there is considerable interest in expanding their use to commercial and scientific applications. Because of the dependence of these vehicles on computer systems, their high degree of autonomy, and the danger posed by a loss of vehicle control, it is critical that the proliferation of these vehicles be accompanied by a thorough analysis of their vulnerabilities to cyberattack.

Participating Students

Andrew Shull

James Goppert

Nandagopal Sathyamoorthy

Contact us

Publications

Journal Papers

Goppert, J., Shull, A., Sathyamoorthy, N., Liu, W., Sciandra, V., Hwang, I., and Aldridge, H., "Hardware and Software Simulation of Cyberattacks on Unmanned Aerial Systems," Journal of Aerospace Computing, Information, and Communication, 2013 (in preparation).

Conference Papers

Goppert, J., Liu, W., Shull, A., Sciandra, V., Hwang, I., and Aldridge, H., "Numerical Analysis of Cyberattacks on Unmanned Aerial Systems," Infotech@Aerospace Conferences, American Institute of Aeronautics and Astronautics, June 2012. Paper

Kim, A., Wampler, B., Goppert, J., Hwang, I., and Aldridge, H., "Cyber Attack Vulnerabilities Analysis for Unmanned Aerial Vehicles," Infotech@Aerospace Conferences, American Institute of Aeronautics and Astronautics, June 2012. Paper

W. Liu, C. Kwon. I. Aljanabi, and I. Hwang, "Cyber Security Analysis for State Estimators in Air Traffic Control Systems," In the Proceedings of the AIAA Guidance, Navigation, and Control Conference, Minneapolis, MN, August 2012. Paper (via AIAA)

Kwon, C. and Hwang, I., "Analytical Analysis of Cyber Attacks on Unmanned Aerial Systems," American Control Conference (ACC), June 2013 (submitted).

Shull, A. and Hwang, I., "Optimal Malicious Estimator Error Injection in Feedback Systems," Infotech@Aerospace Conferences, American Institute of Aeronautics and Astronautics, Aug 2013 (in preparation).

Kwon, C. and Hwang, I., "Security Analysis for Cyber-Physical Systems against Stealthy Deception Attacks," Guidance, Navigation, and Control and Co-located Conferences, American Institute of Aeronautics and Astronautics, Aug 2013 (in preparation).

Open Source Projects

Autonomous Robotics Kit Tools (arktools)

• https://github.com/arktools

PX4 Autopilot

• https://pixhawk.ethz.ch/px4/start
• https://github.com/px4

Motivation

There have been several high-profile cyberattacks recently that demonstrate the vulnerability of these systems.

• Complete command and control capability of Landsat 7 and Terra AM-1, two Earth observation satellites operated by USGS and NASA, respectively, was obtained by unknown foreign agents for several minutes at a time in 2008 [1].
• The US Air Force reported malware infections in UAV control system computers at Creech AFB in 2011. The infection was incidental and did not cause any reported damage, but demonstrates a vulnerability [2].
• A CIA-operated RQ-170 Sentinel stealth drone was captured by the Iranian military [3], with Iranian state-owned TV reporting that this was done by compromising the vehicle software, the command and control center at CIA headquarters in Langley, Virginia, and the satellite link between the two. They reported that the imagery relayed through this satellite link was modified so as to deceive the CIA operators into thinking the system was operating normally [4]. While the drone is known to have been captured, the Iranian claims to a successful cyberattack cannot be verified.

Problem Statement

With the increasing complexity of the networked embedded control technology, unmanned aerial systems (UASs) have become vulnerable to many cyberattacks, and these vulnerabilities have not been thoroughly investigated. Many UASs rely solely on encryption of data channels to prevent cyberattack. While data encryption is a key component of many security strategies, relying on it as the only defense against a cyberattack is misguided.

This is clearly demonstrated by the successful cyberattacks listed above. These incidents clearly demonstrate that it is possible for an attacker to compromise a ground station controlling a UAS and possibly the UAS itself. Since the attacker has application layer control at the source node in these cases, link layer encryption does not protect the UAS. There are also multiple sensor attacks that can be employed by an adversary to corrupt the state of a UAS without needing to break encryption. Examples of these attacks include spoofing GPS or ADS-B signals.

If a UAS were to be compromised by a cyberattack, the consequences could be disastrous. When an individual UAS is compromised, it may fail to complete a potentially vital mission, such as active combat, combat support, military or law enforcement surveillance, fire fighting, or wilderness search and rescue. A compromised UAS may also leak intelligence information, as was the case in 2009 when Iraqi militants were able to view live video feeds from US military UASs. Finally, a compromised UAS poses a significant threat to human life and property if the attacker is able to access any on-board weapon systems or is able to use the vehicle itself as a kinetic weapon. These dangers are amplified when multiple UASs are formed into a network. As more vehicles are added to the network, the number of vulnerabilities that are available for an attacker to exploit increases. Additionally, the communication links formed between the nodes of this network provide new avenues of attack. With the opportunity to compromise more vehicles, the attacker also gains the ability to cause more damage than with a single vehicle.

Attempting to analyze UAS vulnerabilities is a daunting task. A UAS is a cyberphysical system, and ensuring the security of a cyberphysical system requires analysis of the interactions between both the digital and physical components. Additionally, each UAS design is physically unique. The mass properties, propulsion system specifications, sensors, actuators, control system, and aerodynamics of the vehicle all contribute to the system dynamics. The unique dynamics of individual UASs contribute to the vulnerabilities of the system to cyberattack, making a generalized protection system very difficult to implement. A detailed study of UAS cyberattack vulnerabilities has not been previously conducted due to the varied nature of the problem and the lack of a well defined measure of attack severity.

In our research, we seek to identify attack scenarios that exemplify typical attack vectors in a UAS. We then investigate how these attacks can be combined to form more sophisticated attack strategies. The ultimate goal is to identify particularly successful control system attacks and harden the UAS to those attacks in order to improve system security and reliability. Due to the complicated nature of the cyberphysical system, we have not yet developed analytical models capable of predicting the vulnerabilities discovered numerically through simulation.

System Overview

While most current UASs are military systems, there is considerable interest in their use for commercial and civil uses, as shown in Figure 1.

Figure 1: List of future uses for UAVs [5]

In addition to the wide array of uses for these systems, they can also be extremely complex and require considerable amounts of data and network and communication infrastructure to operate successfully. For example, Figure 2 shows the infrastructure employed by the Global Hawk UAS.

Figure 2: Global Hawk UAS Architecture [6]

The architecture used by the Global Hawk represents the military's transition to network-centric warfare, and uses a wide range of remote and local sensors and communication channels, each of which introduce new vulnerabilities to the overall system.

Given the complexity of these systems, their wide range of potential applications, their wide use in networked configurations, and the high cost of failure, including potential loss of life, property, critical military intelligence, and sensitive commercial information, it is vital that they be designed to be robust in the presence of cyberattacks.

Simulation Platform

The FDC/HS Lab at Purdue has developed a high-fidelity simulation platform to model the operations of UASs. The power of this environment is the ability to simulate high-fi delity models using a proven C++ library while interfacing to a block diagram environment. A block diagram environment is very useful for the rapid prototyping and analysis of guidance, navigation and control systems. The current testbed has been utilized by the Purdue Hybrid Systems Lab for analysis of autonomous quadrotors, rovers, and fixed wing aircraft. Figure 3 illustrates the typical analysis process for the unmanned vehicles in the lab.

Figure 3: The Purdue Hybrid Systems Lab simulation testbed.

In order to use the testbed, a vehicle description is first obtained using the wind tunnel if a physical model is available or the USAF Digital DATCOM software. Once the aerodynamics and mass properties of the vehicle are defined, JSBSim (a C++ flight dynamics model library) is used to simulate the vehicle. Next, ScicosLab (a software package similar to Simulink from MathWorks) interfaces with JSBSim. At this point, the block diagram environment within ScicosLab (Scicos) provides a mechanism for rapid analysis. The digital controller can then either be simulated in ScicosLab or implemented using the actual hardware of the unmanned system. Implementing the controller in software is called a software in the loop simulation (SIL), and using the actual hardware is called a hardware in the loop simulation (HIL). Telemetry data from the UAS can then be sent to ground station software to allow complete testing and verification of all user interactions with the unmanned system. In Figure 2, the complete Scicos block diagram used for this analysis is shown. In this diagram, the commands block provides the commanded waypoint and velocity to the vehicle, and the waypoint guidance block uses this information combined with information about nearby obstacles to compute a desired bearing and speed for the aircraft. The backside controller block implements digital PID controllers to regulate the error in the control surfaces. The servos block models the lag in the actuators using the first order transfer functions. The JSBSimComm block sends the actuator signals to JSBSim (the C++ flight dynamics library) where the aircraft state derivative is computed. The ScicosLab block then uses a variable step size integration scheme for propagating the state. The computed state and outputs from the JSBSimComm block are then sent to the sensor models. The sensor models use the state of the aircraft and random noise generation to simulate realistic data from the sensors. This data is then fed into the navigation system. The navigation system uses the sensor information to estimate the state of the aircraft.

Figure 4: Autopilot Model in Scicoslab

In order to determine whether or not a cyberattack has been successful, criteria for failure must be established. Two failure modes have been identified. They are described below. In order to quantify the severity of an attack, the metric we utilized was the time elapsed when any of these failure criteria were reached, referred to as time till failure.

Mission Envelope Failure -- By defining parameters that define restrictions the user would like to place on the vehicle, the vehicle state can be compared to those parameters to determine if the mission envelope has been violated. Examples of potential user-imposed conditions are:

• Mission Theater: a geographic region to which the vehicle is to be confined.
• Target Window: a region centered around a waypoint that the vehicle is to navigate to
• Target Time Window: a time window during which the vehicle should be within the target window
• Battery/Fuel Usage: an acceptable level of resources that are allowed to be consumed during operation

Flight Envelope Failure -- Flight envelope failure is defined as failure of the vehicle airframe. This type of failure typically leads to destruction of the vehicle. In the simulation, this failure is triggered by accelerations and angular rotations large enough to cause airframe failure in the actual vehicle.

Simulation Demonstration

The video below shows the use of the HSL testbed software to simulate a cyberattack. In this attack, the vehicle's estimate of the b component of the attitude quaternion, which is what the vehicle uses to keep track of its pitch, roll, and yaw, relative to the navigation frame, is modified. The result is that the vehicle incorrectly acts as if it were upside down, causing it to crash. The simulation ends as soon as the flight envelope is violated, which in this case means that the accelerations and angular rotations are large enough to cause air frame failure, usually in the form of the wings breaking.

Figure 5: Navigator State Attack Video

This video illustrates the result of a GPS fuzzing attack in all three axes (latitude, longitude, and altitude). This attack inserts random noise into each of these readings, thereby degrading the performance of the autopilot. This is not to be confused with a jamming attack, in which noise is added to the GPS radio signal to prevent any readings from being made. In this case, the noise is large enough that the onboard fault monitoring systems detect the attack and put the vehicle into a trim (glide) state, bypassing the autopilot. This causes the vehicle to drift out of the defined operational theater, violating the mission conditions and resulting in failure.

Figure 6: GPS Fuzzing Attack Video

Simulation Results

The simulation results shown below are examples of multi-axis attacks. These are attacks that use a combination of at least two individual attacks with couple dynamics to affect vehicle operations. These attacks present a more real concern to vehicle safety, as it is possible for a combination of attacks to maintain a smaller profile than a single attack. This becomes very important when the vehicle is using fault detection systems to monitor performance. If an attack is too large, these systems will detect it and work to mitigate its effects. An example of such an attack would be an attack that modifies the performance of a sensor combined with an attack that excites the state being measured by that sensor.

Figure 7 shows the results of a Gaussian noise injection attack in both the IMU yaw gyroscope and the IMU accelerometer. The standard deviation of the gyroscope noise is varied from 0-10 rad/s, and the standard deviation of the accelerometer noise is varied from 0-1 ft/s². The nominal point of zero injected noise in either sensor is in the lower left of the plot. It is clear from this plot that if the accelerometer noise is below 0.3 ft/s² that instability is not possible. Increasing the IMU yaw gyro noise standard deviation does not directly lead to increased stability. If the gyro noise is low, there is a large pocket of instability from 0.55 ft/s² to 1.0 ft/s² accelerometer noise standard deviation. Near 5 rad/s of yaw gyro noise the instability caused from the accelerometer noise is reduced. This complex behavior may be caused by harmonic resonances in the system.

Figure 7: The effect of IMU gyroscope and accelerometer noise on failure time.

A video of this noise injection attack is shown in Figure 8.

Figure 8: IMU fuzzing attack video

The next attack that is considered is an attack that varies the digital update rate from 50 to 100% and injects Gaussian noise with standard deviation varying from 0-1 ft/s² into the IMU accelerometer. The results of this attack are shown in Figure 9. In this plot, the region of instability is fairly heterogeneous. If the processor is running at full speed (100%), the IMU accelerometer noise cannot drive the system unstable with noise less than 0.5 ft/s². Interestingly, when the processor is running at 85%, no simulated accelerometer noise is able to introduce failure. In that sense, a cyberattack that reduces the processor to that rate actually increases the system's resilience to accelerometer noise. As the processor rate decreases, less IMU accelerometer noise is required to induce failure. At 50% processor speed and 0.5ft/s² accelerometer noise there is an irregularity. It is possible that this is due to complex phenomenon such as harmonic resonances within the autopilot.

Figure 9: The effect of IMU accelerometer noise and processor update rate on failure time.

A combination of three attacks is shown in Figure 10. In this attack, noise is injected to the altitude measurement, a phantom ADS-B intruder is inserted and removed with varying frequency, and an initial navigator error in the down velocity is introduced. The failure region is fairly homogeneous except when the initial down velocity error is 50 ft/s, where an unstable pocket can be seen to develop. This pocket constitutes the smallest magnitude attack that causes instability. This case demonstrates the difficulty in protecting cyberphysical systems. The coupling between various system components is so complex that it is very difficult to intuit which attacks cause instability, and the existence of these isolated instability regions can make it very difficult to completely characterize the safe region.

Figure 10: The effect of down velocity error, ADS-B obstacle injection, and GPS altitude noise on failure time.

An undetectable attack is an attack that is not discovered by the fault monitoring systems, an attack that targets an unmonitored subsystem, or an attack that is able to induce an irrecoverable instability before being discovered by the monitoring systems. In Figure 11, the GPS altitude noise is plotted against initial error in the navigator down velocity and the processor is running at 20% of the nominal speed. The 1 sigma, 3 sigma, and 9 sigma measurement ellipsoids are plotted. These ellipsoids represent the ability of the fault detection system to detect an attack. As the attack moves farther from the nominal point, the probability of the attack being detected increases.

Figure 11: The effect of GPS altitude noise and initial down velocity error on failure time with the processor running at 20% nominal speed. The detection ellipsoids for 1, 3 and 9 sigma (covariance ellipsoids) are plotted.

Hardware in the Loop Simulation

This simulation has also been extended to include the analysis of cyberattacks on a real vehicle platform. In the analysis presented above provides valuable data about the vulnerabilities of the underlying continuous dynamics, but in modeling the embedded controller in a block diagram environment, much of the discrete dynamics of the autopilot are abstracted away. By simulating using the actual autopilot, these discrete dynamics are reintroduced, allowing for the analysis of not only of vulnerabilities in the continuous dynamics, but in the coupling of the continuous and discrete dynamics.

With this configuration, it is possible to simulate with the code running on the autopilot hardware or with the code cross-compiled for the simulation PC and running locally, allowing for faster and easier simulation. A demonstration of this second configuration executing in the nominal case is shown in Figure 12. In this simulation, the vehicle has been loaded with a series of waypoints that define a tour of the Purdue campus. The flight dynamics modeling and visualitization and the ground control station that provides the interface to the user are shown.

Figure 12: Simulated vehicle tour of Purdue campus under nominal conditions using ArdupilotMega autopilot

Figure 13 shows the same programmed tour with the digital update rate of the vehicle navigator and controllers having been reduced, simulating a possible cyberattack. As can be seen, this modification disrupts the flight of the vehicle, reducing it to flying in circles over the starting point. It can also be seen that slowing down these executions affects the communications with the ground station, as seen by the periodic red flashing on the ground control station, indicating a loss of communications.

Figure 13: Simulated vehicle tour of Purdue campus under digital update rate attack using ArdupilotMega autopilot

Extensibility to Other Platforms

Given the tight coupling of the discrete and continuous dynamics in cyberphysical systems, this vulnerability analysis will be depend on the physical properties of the vehicle, making a general analysis difficult. The simulation testbed was accordingly developed with the intention that it be easily adaptable to new vehicles and other systems, allowing for easy analysis on additional platforms. This adaptability is not restricted to the fixed-wing aircraft which have been the focus of this analysis, but can include a wide range of air, ground, and underwater vehicles. As a demonstration of this capability, a simulation of a missile system under cyberattack was prepared and can be seen below. Figure 14 shows the missile navigating to a waypoint in the nominal case.

Figure 14: Simulation of missile platform operations in the nominal case.

Figure 15 shows the same vehicle subjected to a digital update rate attack. As can be seen in the center plot, the estimator residuals are very large, indicating very poor performance in the navigation subsystem. Additionally, the vehicle fails to correctly reach the waypoint, as shown in the map plot on the right.

Figure 15: Simulation of missile platform operations subject to a digital update rate attack.

In addition to the analysis of vehicle platforms, this approach can be generalized to cyberphysical systems in general, with wide-ranging applications in areas such as:

• Power Generation/Distribution
• Smart Grids
• Remote Sensing
• Air Traffic Control
• Supervisory Control and Data Acquisition (SCADA)/Industrial Automation
• Transportation
• Medical Devices

As the world becomes increasingly networked and computing and embedded systems become even more ubiquitious, the security of these systems will become a very serious problem. It is imperitive that steps are taken to address the vulnerabilities of these systems before an attack takes place and that sound design practices can be identified and applied to the development of future civillian and military infrastucture.

References

[1] US-China Economic and Security Review Commission, "2011 Report to Congress," http://www.uscc.gov/annual_report/2011/annual_report_full_11.pdf, 2011.

[2] Air Force Space Command, "Flying operations of remotely piloted aircraft unaffected by malware," http://www.afspc.af.mil/news1/story.asp?id=123275647, Oct 2011.

[3] CNN, "Obama says U.S. has asked Iran to return drone aircraft," http://edition.cnn.com/2011/12/12/world/meast/iran-us-drone/?hpt=hp_t1, June 2012.

[4] Press TV, "Iran broke into CIA drone command," http://www.presstv.ir/detail/216399.html, June 2012.

[5] Frost and Sullivan, "Study Analysing The Current Activities in The Field of UAV," Tech. rep., European Commision Enterprise and Industry Directorate-General, 2007.