Suggestion for soft security implementation

[JaehyunShim]

Hi @mikaelarguedas,

Feature request

Feature description

The current instruction says that I have to specify each node to create keys for them (link). I will call it hard security, and I wouldn't call it impractical but I think there should be at least a soft security method. For example, sharing a key between multiple PCs and allowing for message communication only between those PCs will be a simple but very practical way to do that. The current method asks users to regenerate keys every time when they add new nodes or change node names.

On the other hand, I didn't really understand why the current method doesn't even allow for executing nodes without keys registered. Isn't it enough to just block accesses to those nodes with registered keys? I wonder if there is a reason why below should be blocked. $ ros2 run demo_nodes_py listener --ros-args --enclave /talker_listener/listener (key registered) $ ros2 run demo_nodes_cpp talker (no key registered, run this in another terminal, then you will see an error code)

We are actively trying to use sros2 for our robot connected to an open network accessible to random users, so security will be one of the most necessary features. Ryan

[kyrofa]

For example, sharing a key between multiple PCs and allowing for message communication only between those PCs will be a simple but very practical way to do that.

You should be able to pull this off simply by using the same enclave for everything you run.

On the other hand, I didn't really understand why the current method doesn't even allow for executing nodes without keys registered. Isn't it enough to just block accesses to those nodes with registered keys?

That's controlled by the allow_unauthenticated_participants parameter in the governance file that you're welcome to tweak for your use case as you wish. You'll need to re-sign it which isn't as easy as it could be, but it's doable.

[mikaelarguedas]

You should be able to pull this off simply by using the same enclave for everything you run.

+1 One thing worth noting is that if your system is large and everything is in the same enclave you will hit the size limit of the permissions file described in https://github.com/ros-swg/turtlebot3_demo/pull/34#issuecomment-663739230 and https://github.com/ros2/sros2/issues/228

On the other hand, I didn't really understand why the current method doesn't even allow for executing nodes without keys registered. Isn't it enough to just block accesses to those nodes with registered keys?

That's controlled by the allow_unauthenticated_participants parameter in the governance file that you're welcome to tweak for your use case as you wish. You'll need to re-sign it which isn't as easy as it could be, but it's doable.

Another way to do it can be to set the environment variable ROS_SECURITY_STRATEGY to Permissive. It will attempt to find the security material for that enclave, and if it fails, it will create an unauthenticated node instead. The content of the governance file will not apply in that case as the security plugins will not be loaded if the files can't be located, so the node will essentially be a "standard" ROS 2 node with no DDS-Security plugins.

[JaehyunShim]

@kyrofa

Thank you for your advice.

You should be able to pull this off simply by using the same enclave for everything you run.

Yeah, but that has to be done manually by typing one by one (let me know if I am wrong about this point) for all the nodes that are going to be used in the entire system. I do not think that is really realistically pratical unless you are working a very small-sized project like the talker-listener package used as an example in the instruction.

You'll need to re-sign it which isn't as easy as it could be, but it's doable.

I think I should explore the usage of allow_unauthenticated_participants() function first, and what do you mean by re-sign it which isn't as easy as it could be, but it's doable.