We at Canonical have been hard at work on the security features of version 2 of the Robot Operating System (ROS 2). However, if we lift our collective heads up out of the weeds it’s easy to see folks completely misunderstanding how security works today in ROS 2. We’ve written some design articles to help distill all the moving pieces into something comprehensible, but I wanted to do the same here in a slightly less formal way.
ROS 2 uses DDS, an existing protocol with its own specs. It’s out of scope to explain DDS, but there are two important points to make for the purpose of this post:
- DDS is just a spec; there are various DDS vendors that create both open source and commercial DDS implementations.
- DDS supports various security features by way of its DDS-Security spec.
Both of those specs are just as much fun to read as any other spec, so let’s paint a simplified picture of how DDS-Security works.
What is DDS-Security?
DDS-Security is, again, just a spec, and an optional one at that (not all DDS implementations support it). It expands upon DDS by defining a set of plugins with specific purposes and APIs, as well as defining a set of built-in plugin implementations that must be supported by a given DDS implementation in order to be considered in compliance with the spec. It defines five plugins:
- Authentication: Verify the identity of a given domain participant
- Access control: Enforce restrictions on the DDS-related operations that can be performed by a participant
- Cryptography: Handle all required encryption/signing/hashing
- Logging: Provide ability to audit DDS-Security-related events
- Data tagging: Provide the ability to add tags to data samples
ROS 2’s security features only utilize the first three of these plugins. Why? Because those last two aren’t required in order to be compliant with the spec, and thus not all DDS implementations support them. We need to cater to the lowest common denominator, here. Let’s talk a little more about those first three plugins.
Authentication
The Authentication plugin is central to the entire plugin architecture defined by DDS-Security. It provides the concept of a confirmed identity without which further enforcement would be impossible (e.g. it would be awfully hard to make sure a given ROS node could only access specific topics if it was impossible to securely determine which node it was).
The builtin plugin (which is what ROS 2 uses) uses the proven Public Key Infrastructure (PKI). It requires a public and private key per domain participant, as well as an x.509 certificate that binds the participant’s public key to a specific name. Each x.509 certificate must be signed by (or have a signature chain to) a specific Certificate Authority (CA) that the plugin is configured to trust.
Access control
The Access control plugin deals with defining and enforcing restrictions on the DDS-related capabilities of a given domain participant. It’s not apparmor or cgroups, it’s really about limiting a particular participant to a specific DDS domain, or only allowing the participant to read from or write to specific DDS topics, etc.
The builtin plugin (which is again what ROS 2 uses) also uses PKI. It requires two files per domain participant:
- Governance file: A signed XML document specifying how the domain should be secured
- Permissions file: A signed XML document containing the permissions of the domain participant, bound to the name of the participant as defined by the authentication plugin
Both of these files must be signed by a CA which the plugin is configured to trust. This may be the same CA as the Authentication plugin trusts, but that isn’t required.
Cryptographic
The Cryptographic plugin is where all the cryptography-related operations are handled: encryption, decryption, signing, hashing, etc. Both the Authentication and Access control plugins utilize this plugin to verify signatures, etc. This is also where the functionality to encrypt DDS topic communication resides.
So what is SROS 2? It’s ROS 2’s integration with DDS-Security
SROS 2 stands for “Secure Robot Operating System 2.” Understandably, this tends to make folks assume it’s some sort of ROS 2 fork that is somehow secure, and that’s not actually the case. The name is historical: SROS was an effort back in ROS 1 to lock it down, and it was essentially a fork. In ROS 2, the term “SROS 2” is given to the collective set of features and tools in various parts of ROS 2 that are used to enable integration with DDS-Security. So what is that “set of features and tools”?
ROS client library (RCL)
Most of the user-facing runtime support for SROS 2 is contained within the ROS Client Library, a core component of ROS 2. It’s responsible for coordinating the enablement of DDS-Security for each DDS implementation that supports it. It supports three main features:
- Security files for each domain participant
- Permissive and strict enforcement options
- A master on/off switch for all security features
For more details on each of these please read the ROS 2 DDS-Security article.
SROS 2 utilities
Configuring a ROS 2 system to be secure in RCL involves a lot of technology that may be unfamiliar to the average roboticist (PKI, DDS governance and permissions files and their syntax, etc.). The SROS 2 utilities includes the ros2 security tool to help set up security in a way that RCL can use. It includes the following features:
- Create CAs for the Authentication and Access control plugins
- Create a directory tree containing all security files (keypairs, governance and permissions files, etc.)
- Create new identity for a given node instance, generating a keypair and signing its x.509 certificate
- Create a governance file that will encrypt all DDS traffic by default
- Support specifying permissions in familiar ROS terms which are then automatically converted into low-level DDS permissions
- Support automatically discovering required permissions from a running ROS system
Conclusion
I hope that helps clear up any misunderstandings you’ve had about what SROS 2 is and how it works today. We’re always here to help if you have any questions!