How susceptible is ros2 to cyber attacks?

General
1

I have been using ros2 for about 2 years now but only on hobby level. I mostly apply ros2 to control small robots etc.

While I was working on one of my robots, I just had a question in mind, in which I could not really find an answer to, partly because there are a lot of terms I still do not entirely understand and all of the architecture surrounding ros2.

Most of my projects with the small robot relies on Wifi network where I am able to control the robot from different computer under the same network. It is quite a simple setup, but one question I had in mind is, if this were to scale to an industry standard for instance, using a wifi router is not the safest option, but what other methods can I use to ensure the safeness of my robot?

2

It’s really hard to answer a question like “how do I protect my robots from getting hacked” because the answer is always going to be “it depends.” What helps me answer questions like this is using a framework for thinking about security.

All of my robots are operated remotely over the internet and I think about security a lot. I came up with a list of things I wanted to try to protect against, then tried to guess at how likely they were to happen, how severe the result would be if they did, and how much effort it would take to reduce the chance of them happening to some acceptable level.

In the security world, this is called threat modeling.

To take your specific example, you have a robot that runs on wifi, and you’re concerned that a hacker could crack your wifi password. It’s just a hobby robot, maybe you decide that it’s unlikely to happen, but would have really severe consequences if it did. So you come up with a couple ideas. One is to use WPA3 with a long passphrase. That has a low effort to implement, and a high effectiveness of deterring password cracking. Another is changing wifi passphrases every week. That also has a high effectiveness, but would be pretty hard to implement. So, in this case you decide that since the chance of a hack is low, it makes the most sense to skip the second option and implement the first - a strong WPA3 passphrase.

The more scenarios like this that you can come up with, the better picture you will get of how secure (or insecure) your robot actually is.

More generally, the techniques that are used to keep computers secure also apply to ROS robots. Set up a network firewall if your network has internet access, keep your operating system’s security patches up to date, use ssh keys for remote login instead of passwords, etc. If your robot needs to talk over the network, make sure it uses a trusted (or secured) connection. These don’t address specific concerns, but taken collectively they improve overall security.

Regarding ROS itself, I haven’t spent a great deal of time researching its security features. There are some security options in DDS that might be worth exploring.

My approach has been to keep the computers running ROS secure, and not focus on ROS itself too much, because that fits my threat model the best. I also lock the outside doors in my house, not the inside doors :grinning:.

2 Likes
3
2 Likes
4

First off @Khalid_Hersafril, you probably may want to establish clarity between safety and security. Simply put, safety is about making sure the robot doesn’t harm its environment or humans. Security (meaning cybersecurity) in the context of robotics is generally understood the other way around, aims to ensure the environment (and humans) don’t modify the behavior of the robot. You’re interested in the latter, I believe. Second, you should accept that there’s no absolute secure status for cyber-physical systems. This applies to any ROS 2-powered robot. Security is a process. It’s only a matter of time (and how motivated an attacker is) that flaws affecting your system are uncovered (if not already).

As some hint above, the first thing you’d do from a security perspective if you want to understand your robot’s cyber-resilience is to capture your threat landscape. That’s generally done by building a Robot Security Threat Model. Then, following from that, after you’ve implemented security measures, you typically conduct a Robot Penetration Testing exercise (or a red team one) to obtain an experimental measure of how susceptible your ROS 2 robots are to cyber attacks.

A few of us collaborated in the past and built some ROS 2-related open resources that might be helpful to you to get started. Besides the ones mentioned above, these could be helpful:

As a general recommendation, I’d encourage you to check SROS2 project and carefully consider your communication middleware’s security capabilities. Put those in practice when possible but don’t assume these security capabilities will provide any guarantees, as we demonstrated in the past. There’s plenty of flaws still affecting popular middleware implementations and crafting a package that brings down complete remote ROS 2 nodes is still possible today. A way to further mitigate these threats is to harden each one of your robotic systems (considering granularity, via ROS 2 enclaves and based on your resources) and to further tunnel your network communications using a VPN (besides using other security means provided by the communication middleware). I’m quite fond of wireguard these days and works very well with ROS 2.

2 Likes
5

Beyond the proper considerations from the answers above, I’d like to discuss some best practices. For instance, I would not let open ROS 2 ports on a robot deployed in the wild. ROS 2 should run embedded, leaving the ports closed and the robot as independent as possible from any external device.

If connectivity is required, I favor solutions where the robot is the client of web services, and does not open a remote access. If a remote access really is required, I would use a per-robot VPN to reduce the surface of attack. Once connected to it, I would be able to use normal remote ROS clients.

In the case of an industrial setting where several arms share the same network, the VPN endpoint would be moved to the router that handles the network. But note that a specific router is not a requirement in other settings.

6

I’ll second a vote for a VPN approach (also via Wireguard). This is also handy for those cases where you might have a robot in one location, a server doing offboard computation/monitoring in another location, and developers in a third location… put them all on one VPN and you get rid of all kinds of connection hassles.

7

there is a thesis Usable Security and Verification for Distributed Robotic Systems, that you can find Usable Security and Verification for Distributed Robotic Systems (escholarship.org) from the author of SROS2.

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.