ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

ROS2 Security Working Group Online Meeting


Much appreciated :slight_smile: !


@ruffsl there is a lot of great content in this presentation. Are you actively working on all of the items in here? It appears there’s some overlap here in the parts we’re targeting. Specifically:

  • Assistive permission policy generation
  • Descriptive connectivity manifests
  • Procedural provisioning security artifacts
  • Expressive security policy definitions
  • Generation, deployment, revocation of PKI
  • Distributed logging over networks
  • Recording Security Events levels
  • Adding additional automated CI tests

I’d be really interested to see your how you’re thinking about these items and if there’s some way we could collaborate on them.



Hi everyone,

@EndikaGu and I will try to also attend the meeting, even if it’s a bit later for us here in Europe.

We wanted to point out that the RCTF( is already available and open for contributions. As we pointed out on ROSCon, it can be played both online and offline, as the containers for the scenarios are available at GitHub, they are also open for modification and contribution too.

It would be very interesting to propose new scenarios that align with the security strategies of ROS2, so we can both train the security researchers to find weaknesses in misconfigured ROS2 systems, as well as to train developers to take care of the security aspects in ROS2 so they actively enforce them.

Right now the available scenarios only cover the basic aspects, but we are working to include more complex scenarios, and specially, more focus on ROS2. Feel free to point out any feedback or improvements that you would like to see, and of course, feel free to create new scenarios that you would like to be included!


Thanks @olaldiko I appreciate you taking the time out to make it, even though it’s a very inconvenient time. I think it would probably be good to schedule a time more amenable to folks in Europe very soon.



Thanks for organizing. I’m looking forward to the discussion. -Morgan


Thanks to everyone that attended last night! It was a great discussion and I’m happy to find out what people are building related to security. In addition to the summary, I have a recording of the session and will post it as well once I’ve got the logistics worked out. Unfortunately since I did not have anything on the screen for most of the meeting, the video is completely black, however the audio is all there.

We decided to meet again within 2 weeks and I’ll post again once I’ve verified an appropriate time. All future meetings will be held in morning US time so we can make sure to include as wide an audience as possible. If you have problems making the schedule, please let me know.

I am also posting a separate meeting on Thursday AM PDT to have all the folks I unintentionally excluded from Europe due to the timing of the meeting.


  • Reviewed security-related tasks Amazon is delivering for ROS2 Crystal

  • Focusing on simplifying configuration, logging, security development, and community education

  • Review attached presentation for details

    • ROS2 Threat Model
    • Security specific integration tests for eProsima and RTI
    • Security file generator for configuration
    • CMake target for generating configuration for testing
    • Snapshot tool to generate access control (“secure my system”)
    • Recommendations for key/config security
    • Security event logging
  • Ruffin / @ruffsl presented several key items related to SROS2

    • Procedurally Provisioned Access Control for Robotics Systems -
    • Candidate frameworks for automation and testing
      • Keymint - Meta-build system key generation and signed artifacts -
        • Abstract communication language (ComArmor) - graph of subjects and objects and generate artifacts at compile time
        • Maps object or service to DDS mechanisms
    • Scrape metadata about DDS at runtime and build security artifacts for compilation
    • Want to use static verification and include results in security manifest
    • Include all elements, topics/messages/services in the manifest
  • Dynamic topic names - could potentially impact security configuration, are teams doing things like this?

    • Do we need wildcarding or something else to handle salt in topic names?
    • Typical configurations have static connections between nodes along known topic names
      starting point for creating their own threat model
  • Gerardo / @GerardoPardo presented what RTI is currently working regarding ROS security

    • No outstanding plans for ROS2 right now
    • Believe existing patterns can be used for services and parameters
    • Will depend on design of how these elements are implemented on top of DDS
    • If use cases are not covered by existing DDS security specifications, additional support could be needed
    • Data tags could be used by the identity layer / constrains on security
    • Service mapping is using topics and not DDS service names, which means its unclear if changes are necessary
    • What granularity is needed for parameters, all-or-nothing or more granular permissions
  • ROS2 Threat Model

    • Are there existing threat models for ROS2 out there?
    • Will not target a specific robot but be a “cookbook” to enumerate possible threats and provide someone building a specific system
    • Will use a document on github for collaborating on the threat model
    • Come up with a basic template for a threat model
      • Possibly multiple templates because the domain is so large
      • Start with small number of concrete scenarios and try to expand from there
    • SROS2 issue tracker has several long standing issues on the topic
    • Many security papers are already out there to draw upon

    • Impossible to get a single threat model
    • Use STRIDE for modeling threats
    • Focusing on several different areas: anomaly detection, data integrity, and static analysis
    • Ament plugin for pclint and colcon build package to show code coverage
    • Security concerns have been around QNX
      • Preconfiguring the entire system (baked, signed, and shipped)
  • A couple of PRs are out there now for improving how security artifacts are retrieved

    • Currently the keystore directory matches the name
    • PR to traverse the namespace to allow multiple packages with the same name to have separate security artifacts
  • Open question: How do we deal with security failures?

    • What should be the behavior when a node failed to authenticate/authorize?
    • Depends heavily on the implementation, it may be ok to have reduced functionality or could be a critical safety issue
    • Should it be modeled similar to mobile applications, where there is a fallback behavior?
    • Should there be specific actions taken on failure?
    • Need the ability to run in audit mode to find errors
  • Meeting again within 2 weeks

Thursday AM Meeting

I wanted to get a chance to talk to as many people as possible so I’m having another session Thursday morning for folks in other time zones. In the future, I’ll try to schedule meetings such that we can have a single group, however for this first one, I want to give everyone a chance to talk about what their working on.

Thursday, 2018/10/18 @ 07:00 PDT / 14:00 GMT

You have been invited to an online meeting, powered by Amazon Chime.

  1. Click to join the meeting:

Meeting ID: 5568 19 1908

  1. You can use your computer’s microphone and speakers, however, a headset is recommended. Or, call in using your phone:

United States Toll-Free: +1 855-552-4463
Meeting PIN: 5568 19 1908

One-click Mobile Dial-in (United States (1)): +1 206-462-5569,5568191908#

United States (1): +1 206-462-5569

  1. To connect from an in-room video system, use one of the following Amazon Chime bridges:

SIP video system:
H.323 system:

Meeting PIN: 5568191908#

ROS 2 TSC Minutes October 17th, 2018

I have both the presentation and a recording of the meeting available.

Meeting Recording
Meeting Intro Presentation


Thanks @coleray for uploading the recording and the notes from the meeting. See you in the next one!


We had a great second meeting for the folks in other time zones. In attendance were people from Amazon, RTI, Alias Robotics, UCSD, and Acutronic Robotics. Unfortunately I completely forgot to record the meeting so the only artifact is the summary below.

I’m tentatively going to schedule the next meeting for October 30th @ 08:00 AM PDT. Please let me know in the next couple of days if this is not a convenient time, otherwise I will post here with the meeting details.


  • Alias

    • Current in assessment phase for ROS2
    • General check for vulnerabilities
    • Interest in collaborating on threat model
  • RTI

    • Not working specifically on security for ROS2
    • Should parts of DDS need augmentation, happy to collaborate on them
  • Threat model

    • Collaborate via a wiki on SROS2 repo
    • Want to start with a less complex, publicly available system to model as an example
    • Could use the Turtlebot3
    • Victor @ Acutronic offered to use as a possible alternative
  • Should security be exclusive with performance?

    • Need to balance security and performance
    • May want to have subset of nodes secure
    • May only sign or could be sensitive data
    • Publicly known data not very sensitive
    • High performance, high through put topics may not tolerate problem
  • Does the sensitivity of the data merit the performance hit (tf or odometry)

    • Someone could reconstruct sensitive information from non-sensitive data
    • Reconstruct context based on partial information
    • Default should be total security
    • Model how does partial disclosure affect the system
    • There is a paper in the SROS2 tutorial about security, latency, throughput
  • Realtime systems

    • Security on realtime systems could impact the realtime aspects
    • Various security related functions that will need to happen
    • Handshake could cause some non-deterministic elements which would be detrimental to realtime
    • Are there other non-deterministic security related functions that could affect realtime systems?
  • How do we deal with security failures?

    • Extend lifecycle state related to safety of the component
    • Allow system to recover by fixing the issue
    • Could have mediator that fixes the issue
    • This could have problems if nodes begin requesting permissions not needed before
    • Nodes/messages could be marked as critical and cause an error if those messages are not able to be processed due to permission errors
    • Would require the CA to live close to the system
    • Have specific error modes when permission
  • SROS2 tutorial has a walkthrough on securing Turtlebot3

    • Compilation has problems since there’s not a 32-bit build of ROS2
    • Use QEMU to cross-compile
    • Problems getting the XRCE agent with security enabled, could not communicate with the XRCE node
    • Ended up with insecure XRCE nodes and using the RTI router to connect it to the rest of the secure graph
    • Need agent to be able to relay the XRCE traffic under it’s own GUID potentially?

Thanks for everyone for attending!


Next Online Meeting October 30th @ 08:00 PDT

Thanks everyone for attending the meetings last week. As we discussed last week, we want to meet once every 2 weeks in order to make sure we are progressing. I’ve scheduled October 30th @ 08:00 PDT, hopefully this time is more convenient for everyone. Please see below for the online meeting information.

If there are specific topics which came up last week you would like to dive into further, please let me know. Otherwise, I will propose an agenda as we get closer to the meeting date.

You have been invited to an online meeting, powered by Amazon Chime.

  1. Click to join the meeting:

Meeting ID: 9587 67 2748

  1. You can use your computer’s microphone and speakers, however, a headset is recommended. Or, call in using your phone:

United States Toll-Free: +1 855-552-4463

Meeting PIN: 9587 67 2748

One-click Mobile Dial-in (United States (1)): +1 206-462-5569,9587672748#

United States (1): +1 206-462-5569


Meeting PIN: 9587672748#


Hello all, the meeting is still on in 30 minutes. If there are no other suggestions for an agenda, I would like to discuss the ROS2 threat model. Hope to see everyone there!



Hello @coleray,

I missed last call due to some traveling issues but would love to sync.
Is there any follow up call organized? Any chance you could share with us what got discussed?

Many thanks,


Will there be another meeting this coming Tuesday?
I feel like this week skipped by.


+1 here, we skipped the last one. When will it be the next one?


Hello all,

We are working on having the security generation tools out soon, however there are still some questions on the SROS2 front.

SROS2 policy.yaml format does not include services or actions. I would like propose we make following changes to the policy.yaml format.

Using this change: sros2 security cli will gain a new verb using the new node graph API which will automatically generate policy yaml files for a running ros2 system. It will generate a policy.yaml file to secure services and topics, and provide hints (nag) to the developer of which services may need manual permission entry.


Presently, the capabilities for ros topics are distinguished as publish subscribe. I’d suggest we formalise the terminology for the accompanying sub-systems as well for: perimetres, services, actions.
I’d propose the following breakdown of capability primitives:

Subsystem Capabilities
topics publish, subscribe
parameters read, write
actions call, execute
service request, reply

Perhaps others may have suggestions per the exact choice of vocab (e.g. reply vs response) to adopt.

These collection of subject permissions above reflects the symmetry of roles for each given subsystem object interface. Should it be necessary, we should anticipate the extending the number of capability types. For example, while the pub/sub server/client roles in topics and services are rather straightforward, what of finer restrictions when provisioning for parameters and actions? Should practices such as same origin policy be implementable when controlling who can cancel who’s particular goal, or who can write to which particular parameter?

Related comment on actions:


I’m happy with being more verbose and distinguishing ros communication with capabilities, I will revise the ipc subsystem to have different names for capabilities.

DDS topic mangling

Is there a discussion regarding the translation of yaml -> dds xml DomainParticipant permissions document is concerned?
I’ve observed that each rmw implementation mangles topic names based on the subsystem (topic, actions, services) using constants replicated through each repo. Is there a thread which discusses consolidation of topic prefixes/suffixes into a library to ensure each implementation uses the same constants? This way we can programmatically ensure the generated permissions xml document is accurate to each rmw implementation.

Notes on ruffsl capability primitives

We will need to distinguish the differences between parameters and the rest of the “subsystems.” With the above structure, read/write refers to the remote node requesting an operation on the parameter node (outputs) whereas all other subsystems have an input/output capability defined. That convention means we will need to “whitelist” all nodes to be able to reply (output) to parameter read/write requests. The new yaml definition would look as follows:

SROS2 yaml policy changes


name description
access_permission The access permission of that node for the specified icp
ipc Inter-process communication, how messages get from one node to another
ipc identifier The specific subsystem id to provide access to (topic name, service name…)
ipc types The inter-process communication subsystem (topics, services…)


Most ipc permissions are given on a client/source basis.
Parameter permissions are slightly different. These specify whether this node is allowed to read/write to another node.

ipc_type identifier access permission options
topics topic name subscribe, publish
services service name request, reply
actions action name call, execute
parameters node_name read, write

Policy yaml file layout



The documentation for mapping from ROS2 to DDS (for topics and services at least) is documented under this design page: Topic and Service name mapping to DDS.

The mapping for ROS2 actions and parameters to DDS topics spread across elsewhere. I’m not sure sure how much has been settled upon; I still don’t like the use of tokens for action namespaces: my comment.

As per the yaml format; I first went with yaml for SROS1 as a quick and dirty way of clobbering a configuration file for the SROS1 keyserver, and so this was then merely first adapted for SROS2. However, since SROS1, I’ve come to realize the many setbacks in using such a lose and unstructured format for mission critical definitions, siverly hamstringing any configuration parser’s maintainability, extensibility, and interoperability.

To improve upon the permission configuration format, I’d like to provide users a precise schema definition to help strongly type the security configuration format, yet facilitate successive versioning. As ROS2 already make much use of XML for the package.xml and DDS permissions.xml files, XML seems a logical choice to start with for being both easly machine parsable/verifiable, still human readable but also easly composable and recursive, allowing for more succinct, structured policy profile formats.

In the linked schema folder below, I’ve been iterating on XSD files, inspired by AppArmor’s mandatory access control syntax, to enable stadertized the parsing of permission configuration files so we expand tooling development in the community while maintainer interoperabile format and interpretation:

To help illustrate the use of the schema, I’ve updated my working examples in keymint to use this format to interpret and generate the security artifacts a talker listener example, by compose common permission primitives into reusable modules of recursive or repeated imports. This presently takes into consideration the capabilities discussed above. See the outer comarmor.d folder here as well:

Lastly, as an example of parsing the operation on the XML DOM, like filtering or quring elements, here is a jupyter notebook that illustrates the interpretation of the modularized permission profile above into a single XML element tree for consecutive operations.


Completely agree here, while the documentation is under a design page, every rmw implementation has a very similar structure. My question alludes to the numerous duplicate definitions in each rmw implemention layer instead of defining these constants in the rmw interface layer.

I’m interested in a strongly typed, structured permission file as well. However, we also need a timeline for when/what we will be changing is sros2. I would like to enable security by default. In other words, reduce the amount of overhead to develop and deploy ROS2 with security on. These features are summarized here.

One of these features generates the policy.yaml file from a running ROS system. This allows developers/deployment engineers to use an sros2 command line tool to generate their entire system’s policies. The status of this feature is that it currently works with the node graph implementation and secures topics with sros2 create_permission verb. We would like to push these features for ROS2 users sooner rather than later. @ruffsl do we expect these sros2 changes to occur soon, or should we simply change the yaml definition for now to secure services?

Generate an sros2 yaml permissions file with the permissions of every visible node
on the dds network.

Example: run the minimal_publisher_lambda node
Execute: `ros2 security generate_permissions node_policies.yaml`

It will create the node_policies.yaml file in the current directory:
          allows: rr
          allows: ps
          allows: p


Security by default is an an admirable yet ambitious goal for crystal deadline. I think the most challenging aspect would be in making user aware of the security deployment process and integrating the access control provisioning pipeline into the the development cycle. Without the necessary level of documentation and/or setup wizards, I feel most users would just disable it out of frustration due to the added unforgiving contratinets and tedious manual interventionen in managing the permission after each system change.

Perhaps as a short-term compromise, we could encourage users to at the least enable authenticated encryption by default in the install instructions docs, and forgo node level access control until we can better integrate it in the next release. Given no access control, and nodes running on a common machine and user, there wouldn’t be much incentive in making new key material for each node, as the capabilities of each would be equivalent regardless of differentiating identity.

An example for setting up only authenticated encryption for a single development machine:

# Create keystore with single development keypair
mkdir ~/.ros && cd ~/.ros
ros2 security create_keystore keys
ros2 security create_key keys dev
# Encrypt or move certificate authority's private signing key
cd ~/.ros/keys
openssl rsa -aes256 -in ca.key.pem -out
mv ca.key.pem
chmod 600 ca.key.pem
# ROS2 nodes running on same USER share development keypair
export ROS_SECURITY_NODE_DIRECTORY=/home/$USER/.ros/keys/dev

If all you’d like to add is support for ROS2 service, then modifying the existing yaml structure and extending its custom parser logic would be simple enough. However, if you’d like to add support for action, and parameters as well, I think it would be wise to first invest in a formal policy profile schema that we could then build intermediate compiler agents to carefully translate the ROS2 substem objects into DDS substem objects for Secure DDS permission definitions.

This is the logic that I’ve breaking out into the keymint_keymake package, given that the translation from a Mandatory Access Control policy profile of ROS2 substems to an ordered nested list Secure DDS grants is non trivial for the general case; particularly when interlaced deny permissions must be gaertied to take precedence over respective allow permission they effect, and that accidental crossover of permissions are not introduced when remapping subsystem capabilities.