Integrating ROS2 security with Zenoh

[ros2torial]

Hi,
We have used ROS2 security on the robot IPC and want to use zenoh to transfer the messages to cloud, but it seems like zenoh-bridge-dds doesn't have any feature to include ROS2 or DDS security feature. The security which we have used includes new nodes if the security environment variables are available. We also tried running zenoh dds bridge as a node but that also didn't work.

ros2 run zenoh_bridge_dds zenoh_bridge_dds -c client.json -d 4

Without security everything is working fine, but in order to keep everything secure we want to use ROS2 security.

[JEnoch]

The zenoh-bridge-dds relies on CycloneDDS but currently built without the DDS security enabled.
We were forced to do this for 2 reasons:

1. Rust requires static linking with CycloneDDS. And CycloneDDS doesn't support the build of static libraries with security enabled.
2. Cross-compilation requires OpenSSL library to be available for the target platform. And that's not the case by default with the cross-rs (see https://github.com/cross-rs/cross/wiki/FAQ#openssl-is-not-installed)

Also, zenoh-bridge-dds is not implemented as a ROS2 node, but as a pure DDS Participant. Therefore, the bridge doesn't contain the RCL code that manages the SROS2/DDS Security setup as detailed here: https://design.ros2.org/articles/ros2_dds_security.html#dds-security-integration-with-ros-2-sros-2.

Therefore, supporting SROS2 would require some non-trivial changes in zenoh-bridge-dds and probably CycloneDDS.

Out of curiosity, why do you need security for inter-process communications in a robot ?
They should go over the loopback interface only (or better: via shared memory). Thus, only someone logged with privileges or with physical access to the robot could eavesdrop the IPC, right ?

[ros2torial]

Hi @JEnoch, Thanks for the explanation!
So, in order to receive SROS2/DDS Security messages using zenoh-bridge-dds, we have to change a lot in zenoh-bridge-dds and maybe in CycloneDDS.

Out of curiosity, why do you need security for inter-process communications in a robot ?
We are using security in ROS2 communication of robot so that even if someone hacks into the IPC and publish on cmd_vel or on any hardware critical topic, the subscriber won't accept the it. Also topics won't be visible if we do ros2 topic list or ros2 topic echo as the security info will be required to access it.

They should go over the loopback interface only (or better: via shared memory). Thus, only someone logged with privileges or with physical access to the robot could eavesdrop the IPC, right ?
We are already using ROS_LOCALHOST_ONLY=1 so that the robot IPC remains isolated even if any other IPC which is connected to same network has same DOMAIN_ID. Here for more security we also want to implement SROS2/DDS Security in robot IPC.

[ros2torial]

@JEnoch If we use zenohd here then, will the DDS security data be detected by zenoh?

Also, enabling DDS security is very important in our application to provide additional layer of security of the system. It would be better if zenoh can incorporate DDS security.

[JEnoch]

For clarification: zenohd itself doesn't do any DDS protocol. That's the role of the Zenoh plugin for DDS (libzplugin_dds.so) that can be loaded by zenohd per configuration.
This plugin is also provided as a standalone binary named zenoh-bridge-dds.

That said: libzplugin_dds.so and zenoh-bridge-dds run the exact same code wrt. DDS features.
So yes, if DDS Security support is implemented in eclipse-zenoh/zenoh-plugin-dds, it will benefit for both libzplugin_dds.so and zenoh-bridge-dds.

But I'm not sure what you mean with "detected". Could you please clarify ?

We've taken in account your request for DDS Security support. We'll decide soon if we include it in our short term roadmap.

[ros2torial]

In this webinar video, there is a slide where it is mentioned that

zenoh DDS Plugin is
•Dynamic library (in Rust)

and zenoh-bridge-dds is Standalone:
•Same plugin but statically linked

So I thought that zenoh-bridge-dds won't work with DDS security as you mentioned above that it is statically linked. I thought that if we use zenohd with DDS Plugin then it may work as it is dynamic library.

But I'm not sure what you mean with "detected". Could you please clarify ?

If a ROS2 publisher node is using DDS security then zenoh-bridge-dds won;t be able to detect it.

[JEnoch]

So I thought that zenoh-bridge-dds won't work with DDS security as you mentioned above that it is statically linked. I thought that if we use zenohd with DDS Plugin then it may work as it is dynamic library.

Sorry for the confusion. What I meant is that for both cases (zenoh-bridge-dds and libzplugin_dds.so) CycloneDDS is statically linked within those binaries. So when this issue of building a static CycloneDDS lib with Security enables will be solved, DDS Security will be supported by both zenoh-bridge-dds and libzplugin_dds.so).

If a ROS2 publisher node is using DDS security then zenoh-bridge-dds won;t be able to detect it.

If zenoh-bridge-dds is configured with appropriate credentials (i.e. same or compatible with the ROS2 node), it will be able to discover the ROS2 publisher.

[cguimaraes]

In addition to what @JEnoch just mentioned (here), if your purpose it to have a secure data transmission from your robot (or Zenoh-DDS-Bridge) to the cloud, you can make use of TLS or QUIC transports in Zenoh.

By doing so, in your DDS domain you use DDS security features and in Zenoh domain TLS or QUIC.
Would that be sufficient for you?

[ros2torial]

Hi @cguimaraes , Thanks for the reply!
For securing data transmission from the robot to the cloud, we are already planning to use of mTLS feature of Zenoh. In addition to it, the ROS2 communication inside IPC should also be secure, that's why we are using SROS2/DDS Security. The problem here is that zenoh-bridge-dds doesn't detect DDS secure messages and I didn't find any setting or environment variable which can facilitate it. If zenoh-bridge-dds is able to incorporate DDS secure messages even in encrypted form, then it will really make the whole system secure from IPC to cloud.