Install a recent version of OpenSSL (1.0.2g or later)
brew install openssl
You will need to have OpenSSL on your library path to run DDS-Security demos, you can do this by running:
export DYLD_LIBRARY_PATH=`brew --prefix openssl`/lib:$DYLD_LIBRARY_PATH
For convenience you can add this export to your bash_profile.
First install ROS2 from binaries following these instructions.
Setup your environment:
source . ~/ros2_install/ros2-osx/setup.bash
In the rest of these instructions we assume that every terminal setup the environment as instructed above.
For OpenSSL to be found when building code you'll need to define this environment variable:
export OPENSSL_ROOT_DIR=`brew --prefix openssl`
For convenience you can add this export to your bash_profile.
Install ROS2 from source following these instructions.
Note: Fast-RTPS requires an additional CMake flag to build the security plugins so the colcon invocation needs to be modified to pass:
colcon build --symlink-install --cmake-args -DSECURITY=ON
Setup your environment:
source ~/ros2_ws/install/setup.bash
In the rest of these instructions we assume that every terminal setup the environment as instructed above.
To use DDS-Security with Connext you will need to procure an RTI Licence and install the security plugin. See this page for details on installing the security plugins.
We will now create a folder to store all the files necessary for this demo:
mkdir ~/sros2_demo
cd ~/sros2_demo
ros2 security create_keystore demo_keystore
ros2 security create_enclave demo_keystore /talker_listener/talker
ros2 security create_enclave demo_keystore /talker_listener/listener
export ROS_SECURITY_KEYSTORE=$(pwd)/demo_keystore
export ROS_SECURITY_ENABLE=true
export ROS_SECURITY_STRATEGY=Enforce
These variables need to be defined in each terminal used for the demo. For convenience you can add it to your bash_profile
.
ROS 2 allows you to change DDS implementation at runtime.
This demo can be run with FastDDS / CycloneDDS / ConnextDDS by setting the RMW_IMPLEMENTATION
variable, e.g.:
export RMW_IMPLEMENTATION=rmw_fastrtps_cpp # or
export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp # or
export RMW_IMPLEMENTATION=rmw_connextdds
Note that secure communication between vendors is not supported.
Run the talker
demo program:
ros2 run demo_nodes_cpp talker --ros-args --enclave /talker_listener/talker
In another terminal (after preparing the terminal as previously described), we will do the same thing with the listener
program:
ros2 run demo_nodes_py listener --ros-args --enclave /talker_listener/listener
These nodes will be communicating using authentication and encryption! If you look at the packet contents on e.g. Wireshark, the messages will be encrypted.
Note: You can switch between the C++ and Python packages arbitrarily.
These nodes are able to communicate because we have created the appropriate keys and certificates for them.
To be able to use the ros2 CLI tools to interact with your secured system, you need to provide it with an override enclave:
export ROS_SECURITY_ENCLAVE_OVERRIDE=/talker_listener/listener
Then use the CLI with --no-daemon
and --spin-time
:
Note
Avoid using ros2 daemon
since it may not have security enclaves, and enough time duration should be given for the discovery in secured network.
ros2 node list --no-daemon --spin-time 4
/talker
ros2 topic list --no-daemon --spin-time 4
/chatter
/parameter_events
/rosout
ros2 topic echo /chatter --spin-time 4
[INFO] [1714897092.882384995] [rcl]: Found security directory: /root/sros2_demo/demo_keystore/enclaves/talker_listener/listener
data: 'Hello World: 257'
---
data: 'Hello World: 258'
---
The previous demo used authentication and encryption, but not access control, which means that any authenticated node would be able to publish and subscribe to any data stream (aka topic).
To increase the level of security in the system, you can define strict limits, known as access control, which restrict what each node is able to do.
For example, one node would be able to publish to a particular topic, and another node might be able to subscribe to that topic.
To do this, we will use the sample policy file provided in examples/sample_policy.xml
.
First, we will copy this sample policy file into our keystore:
git clone https://github.com/ros2/sros2.git /tmp/sros2
And now we will use it to generate the XML permission files expected by the middleware:
ros2 security create_permission demo_keystore /talker_listener/talker /tmp/sros2/sros2/test/policies/sample.policy.xml
ros2 security create_permission demo_keystore /talker_listener/listener /tmp/sros2/sros2/test/policies/sample.policy.xml
These permission files will be stricter than the ones that were used in the previous demo: the nodes will only be allowed to publish or subscribe to the chatter
topic (and some other topics used for parameters).
In one terminal (after preparing the terminal as previously described), run the talker
demo program:
ros2 run demo_nodes_cpp talker --ros-args -e /talker_listener/talker
In another terminal (after preparing the terminal as previously described), we will do the same thing with the listener
program:
ros2 run demo_nodes_py listener --ros-args -e /talker_listener/listener
At this point, your talker
and listener
nodes should be communicating securely, using explicit access control lists!
Hooray!
The nodes will not be able to publish/subscribe to topics not listed in the policy.
For example, the following attempt for the listener
node to subscribe to a topic other than chatter
will fail:
# This will fail because the node is not permitted to subscribe to topics other than chatter.
ros2 run demo_nodes_py listener --ros-args -r chatter:=not_chatter -e /talker_listener/listener