ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

ROS2: Security tools for development and production

ros2

#1

Hi all, my team at Amazon is looking for your input on security tools!

Summary

Developers looking to secure their robots and actively develop new nodes will have to manually create keys and policies, as well as debug their node connectivity should security not be set up properly. Conversion from an unsecure DDS to secure DDS may also have a performance impact, therefore developers will need to test and develop with security enabled for production.

SROS2 has done an excellent job creating their own wrappers to demonstrate the security capabilities of FastRTPS and RTI Connext. With this in mind, we want to bring forth three tools to make security quicker and less error prone for developers.

Manual Key Generation

Developers need to manually run generate keystore, then generate key for each of their nodes.
This is error prone for developers since we often use docker containers, different machines, direct development on the robot, and all the amazing ways we like to create robots.
Solution: cmake build macro
We would like to present a cmake macro for generating the key and keystores during build time. Our macro uses SROS2 on the back end, but the macro definition should stay the same should a team want to define their own security generator. This enables each developer to have the expected authentication without having extra steps at run time. The ROS security environmental variables will still need to be set outside the macro.
ros2_secure_node
# NODES (macro multi-arg) takes the node names for which keys will be generated
# SECURE (cmake arg) if not define or OFF, will not generate key/keystores
# SECURITY_DIR (cmake arg) if defined will be the location of the keystore (it will be created if it does not exist). A message will be generated to a default location should SECURITY_DIR not be defined
# SECURITY_KEYSTORE (cmake arg) if defined will be the name of the keystore (it will be generated if it does not exist)
# POLICY_DIR (cmake arg) if defined, will compile policies by node name into the access private certificates (e.g POLICY_DIR=/etc/policies, Generate: <node_name> /etc/policies/<node_name.yaml>)

ros2_secure_node(NODES node_name_1 node_name_2 ...)

Manual Policy Inspection and Generation

Access policy generation is manual.
A release engineer or developer would need to inspect the node graph, all services, and soon actions to create policies for each node. We are considering creating two tools for easing deployment to production security and debugging.
Solution: Node Graph Tools

  1. A node graph inspection tool will be available to take a snapshot of the node graph and generate policies for each node. It will print feedback on nodes which advertise services and actions, which developers will use to add permissions for client nodes.
  2. (OPTIONAL) rqt_graph modified with permissions, such that a developer can inspect their system and visualize the access control of their nodes.

Quality and Performance Test

Performance between DDS providers with security on and off
Developers will be using ROS2 for a myriad of applications, and teams will want to know the effects of choosing certain providers over others, and the level of security they need. ApexAI provides their repository (https://github.com/ApexAI/performance_test) which we will use to run a series of performance tests with and without security to prevent regression and understand system impact.

Will these tools help you?
What other requirements would be helpful for each of these tools?


ROS 2 TSC Minutes October 17th, 2018
ROS2 Security: CLI tools
#2

Thanks for putting this together! Although not formally a command line tool, our team at Alias Robotics has been working on the Robotics CTF (RCTF). An online environment for penetration testing. RCTF can run both in our servers or locally through Dockerized scenarios (https://rctf.aliasrobotics.com).

We are making very active use of this with our clients and are more than happy to contribute with support and maintenance to the community.
In addition to the availability of the RCTF, we’d be happy to put person-power and create custom scenarios for sensitive security aspects within ROS 2.0. This way, evaluation is simplified and easily accessible to a wide variety of security researchers


#4

Deliverable status:

cmake build macro
Status: In Code Review
Deadline for release: 11/7/2018

Access policy generation
Status: Blocked on Node Graph API
Deadline for release: 11/14/2018

Node Graph API
Status: Started for eprosima Fast-RTPS
Deadline for release: 11/14/2018
See: ROS graph information tools implementation discussion

Quality and Performance Test
Status: Upcoming
Deadline for release: 11/16/2018