Security for the Robot Operating System

Highlights

• Evaluation of ROS security and detailed description of possible attacks.

• Light-Weight precautions to harden ROS at application-level.

• Minimally invasive changes towards hardening the ROS core.

• Penetration testing tool support for ROS.

• Usable security and key-management in ROS.

Abstract

Future robotic systems will be situated in highly networked environments where they communicate with industrial control systems, cloud services or other systems at remote locations. In this trend of strong digitization of industrial systems (also sometimes referred to as Industry 4.0), cyber attacks are an increasing threat to the integrity of the robotic systems at the core of this new development. It is expected, that the Robot Operating System (ROS) will play an important role in robotics outside of pure research-oriented scenarios. ROS however has significant security issues which need to be addressed before such products should reach mass markets. In this paper we present the most common vulnerabilities of ROS, attack vectors to exploit those and several approaches to secure ROS and similar systems. We show how to secure ROS on an application level and describe a solution which is integrated directly into the ROS core. Our proposed solution has been implemented and tested with recent versions of ROS, and adds security to all communication channels without being invasive to the system kernel itself.

Introduction

The shift towards industry 4.0 implies stronger automatization and hence increased relevance and use of robots. An Industrial Control System (ICS) is inherently distributed and connects a potentially huge number of sensors and actors, whose orchestration exhibits complex dynamics that are typically fragile and hence vulnerable to attacks. This new technology and the tight integration and interconnection of components leads to new vulnerabilities and thus a heightened focus on the security concerns. The particular evolution of the Robot Operating System (ROS) happened under time-pressure of industry,¹ which has assigned a secondary (if not ternary) role to security.

In ICS, the traditional information security triad of Confidentiality, Integrity and Availability (Confidentiality, Integrity, Availability (CIA)) will often be assigned different priorities [[1], [2]]. When thinking of user data in information systems, it is usually more important to keep them confidential than available. Thus, taking a service offline in response to an attack is often a reasonable reaction.² In information systems, lost data can often be restored from backups. However, actions taken by an ICS (e.g., an actuator damaging its surroundings) cannot simply be undone by “restoring from the last known good backup”. To give two examples, if a drone or a hydro dam is under attack, simply shutting them down is not a valid response. Above all other considerations, such systems’ basic functionality must be available until they reach a safe state (e.g., the drone has landed or the water reservoir held back by the dam was drained).

The development of ICS has been paralleled by the attack strategies adapting themselves to the increasing complexity of the victim systems. The resulting highly complex and extremely well coordinated attacks known as Advanced Persistent Threats (APTs) [[3], [4]] dramatically demonstrate the need for security to become an intrinsic part of the design of a distributed system, rather than a subsequent add-on that is considered once the availability goal has been reached.

In fact, even though safety beats security in terms of priority, there is no reliable safety without security. Just imagine the safety precautions of a robot to depend on reliable sensor data. Injecting malicious packets to mimic some dangerous situation that forces a robot to react can already cause harm by itself. Blocking messages can be equally dangerous, if the dropout message was a notification of a human being in the robot’s way. These two examples (among more to follow in Section 3) already exhibit security as a necessity for safety, and indirectly, also for availability, since accidents typically induce temporal shutdowns of the production system (and hence economic damages).

This article discusses a series of proposed improvements to ROS, which have been motivated by the reported vulnerabilities and insufficiency of ROS regarding security [[5], [6], [7], [8]]. Specifically, we will develop our discussion along the following skeleton: we let a brief survey of related work motivate our work by showing the recognition and interest of the community (industrial and scientific) to the problem of securing ROS. In Section 3, we provide an analysis of ROS vulnerabilities along with a detailed description on how an attacker would perform a manipulation of a ROS application. We then review prior work concerning a security architecture to harden ROS on the application level (OSI layer 7), and to harden the ROS core (in OSI layer 4), described in Sections 4 Hardening ROS on the application level, 5 Securing the ROS communication channel.

To validate the efficacy of the security added to ROS, we use Section 6 to compare the behavior of a “plain” ROS and a hardened version thereof against a fixed attack pattern. That is, we describe a practical testbed including a dedicated tool for penetration testing ROS where messages are injected to see how easy the system can be manipulated, unless cryptographic precautions are implemented. In fact, their implementation is neither heavy weight nor difficult, and our findings are that even a cryptographic light-weight armory can do quite well already.

Cryptography, however, is insufficient by itself and depends on proper and especially simple key-management. Most legacy systems, up to ones under construction today, are designed to be repaired quickly and easily. For example, if a module needs to be replaced, the service staff should not be required to do more than unplug the malfunctioning module and replace it with the new one. If cryptography comes into play, keys are stored all over the system, and replacing a module with a new one requires refreshing the keys inside the whole system. A proper key management is far from trivial and can make cryptography cumbersome (if not infeasible) to apply.

Our proposed security enhancements for usable key-management (see Section 7.1) therefore heavily rely on smart cards and tamper proof (sub-)modules to handle the key management transparently for the engineers. This is to the end of designing modules so that they, upon replacement, are capable of automatically registering themselves with the system, while the required level of authenticity, genuineness and secure logging are all assured.

The latter is a particularly important matter of forensic investigation in case of system failures (in the worst case, involving harm to humans). This leads to accountability as an independent requirement beyond CIA (or better “AIC” in industrial systems), and must be considered separately. We discuss the matter as part of the outlook and follow up work to this article (in Section 7.2).

Our work proposes a security architecture on the application layer, along with a practical implementation and validation thereof. Since plain ROS offers only limited native security, and changes to the operating system (i.e., below the application layer) are usually nontrivial and expensive, the question of how much security can be added “on top” arises. The main message and novelty of this work is the finding that (first) ROS can be hardened on the application layer to a wide extent, and that only a relatively thin layer of (cryptographic) security implemented below layer 7 already thwarts many known attacks (at the appeal of using existing “off-the-shelf” mechanisms and technology). The contribution of this work is complemented by the verification of the additional security, by demonstrating the newly gained resilience of our hardened ROS against attacks reported in the related literature, and a demarcation of the line between what can be done on the application layer and which security aspects must be rooted deeper or even outside the operating system. This discussion constitutes the outlook in Section 7. We believe this matter to be an important one besides purely technical aspects, and hope to stipulate related research along these lines, motivated by the new findings in this paper.