Expose secure communication only with specified entities

Hi ROS developers,

Asking thoughts and ideas!

I think this is more like discussion to explore than a question, I would like to have feedback from the community how to handle this situation to support 3rd party device.

Original issue: Expose secure communication only with specified entities. · Issue #326 · ros2/sros2 · GitHub

  • For performance consideration, it would be better to keep the localhost communication in robot without secured authentication nor encryption. (basically it uses localhost in robot system, but some specific nodes to be exposed.)

I am trying to find out what could be best solution to support above requirement with secured communication with sros2.

If you have any experience, please enlighten me :pray: :pray: :pray:

Regards,
Tomoya

2 Likes

ASAIS, 3.12. Secure communications with ROS 2 Router — Vulcanexus 1.0.0 documentation could be the solution to route the different ROS 2 network with security enclaves? Is there anything else???

A security use case :slightly_smiling_face:!

Happy to try and help @tomoyafujita. Though I might be misunderstanding some aspects of your initial problem description, so feel free to clarify.

Here’s my understanding:

Your requirement is to maintain high-performance communication within the Awesome robot by keeping local communication unsecured, while enabling secure communication (ROS 2 security by means of an implementation of the DDS Security plugins) only with specific external entities, e.g. End user's PC (authenticated). Then, you have another End user's PC /Device (unauthenticated) which is not making use of such security mechanisms, that you want it interacting with Awesome robot.

My take on this is that technically, what you’re trying to do implies enabling an attack vector into your Awesome robot since you’d be requiring some sort of Insecure Node (Pub/Sub) or alternative interface (does not necessarily need to be a complete ROS 2 Node, with all abstractions for interop.).

So, if I’m not mistaken, I believe that you’re hoping to achieve something as:

To do so, you could rely on third party components, as you suggest, but that assumes those components mitigate such security flaw, so your security would be reliant on them. My suggestion is to avoid that decision, as adding more complexity to your system difficults its security (security and complexity aren’t best friends), and your internal security assessment actions.

Instead, you can technically enable this by implementing your own bridging within Insecure Node (Pub/Sub) via already used and assumed security-reliable technologies. E.g. inter- or intra-process communications and handling discovery via fixed identifiers (e.g. IP). Regardless of which technical avenue you use for interoperability, mitigating this security flaw is needed.

To do so, I’d suggest (again) you rely on technology that’s already present in your system and assumed/assessed/tested (something you should validate experimentally via a pentest or similar exercises) as secure. In particular, I’d go for something like network segregation, or specifically logical network segmentation. A great way to do so is using a VPN. Wireguard works great in my experience and plays along with ROS 2.

By doing so, despite not having security at the application layer, you’d be adding security at the network layer. It could be understood as something like:

I would also consider extending such VPN to the overall setup. Depends on your use case latency requirements, but definitely worth it in in many scenarios. Taken from some work last year we’re yet to publish:

(VPN implementation in this case corresponds with Wireguard)

3 Likes

I think it is possible by eporisma integration services, If you use eporisma as middleware. However I am not sure How secure It will be, as I am not experienced in this topic
https://integration-service.docs.eprosima.com/en/latest/examples/same_protocol/ros2_change_domain.html

@vmayoral

your understanding is exactly right :+1:

thank you very much for all the informative comments!

Instead, you can technically enable this by implementing your own bridging within Insecure Node (Pub/Sub) via already used and assumed security-reliable technologies.

yeah this is what we can do for sure, and we can have full control for our security requirement.

E.g. inter- or intra-process communications and handling discovery via fixed identifiers (e.g. IP).

the thing is that, our Awesome robot goes to end-user and/or public environment, we are trying to avoid the solution that could generate any user’s burden.

i think you are getting some pictures on this Awesome robot with your experience … :sweat_smile: :sweat_drops:

we are not saying we never do that, but it is all about balancing requirements and user-experience.

despite not having security at the application layer, you’d be adding security at the network layer

yeah agree. actually this is one of the candidates that we have been considering.

our thought is to use mTLS handshake between them in the operating system layer, so that nobody in the robot system needs to be bothered unless it goes to the outside of the system.

besides, this is agnostic from application framework, so that we can keep the security modularity more.

I would also consider extending such VPN to the overall setup. Depends on your use case latency requirements, but definitely worth it in in many scenarios.

thank you for sharing the performance comparison.

and totally agree with you, this depends on data-plane latency and performance requirement, that we need to consider more details, but obviously one of the candidates.

thanks,
tomoya

@mnumanuyar

thanks for the information.

as far as i know, 2.2. ROS 2 Domain ID change — Integration Service 3.1.0 documentation is meant to bridge/proxy the different framework or domain, but security purpose? Do you happen to know that if we can bind the security enclaves to them? (Probably I should ask friends from eProsima…)

CC: @MiguelCompany @Jaime_Martin_Losa

thanks,
tomoya