Extending SROS2 command line tooling

Niklas974 · 2020-08-28T16:17:08.967Z

I have looked at the SROS2 tooling provided with foxy and on github
It feels like the command line tooling is currently designed to set up demo keystores with demo keys but does not seem fit to be used in a productive environment. A security professional will be able to manually create the keys and certificates needed and will be able to handle them appropriately. This can be challenging for somebody with less of a security background, though.
For example, creating the node private keys at the CA is very unconventional and could have negative impacts on the security - depending on the scenario. I think support for creating CSRs on nodes to be signed at the CA should be added. This would also improve compatibility with existing CA infrastructures, which might be beneficial to organizations who prefer to use a separate CA (e.g. to make revocation easier).
Additionally, the documentation should be improved. I have seen cases where the whole keystore was copied to each machine because the user did not understand the concept, thus defeating the whole point for Access control.

I would like to hire a student to work on this, this would involve some major extensions to the existing code and most likely some refactoring. My goal is to keep the command line tooling as simple as it is know, while adding flexibility to make it easy to securely use it in production environments.
Could you advise, on how to proceed with this? Due to my background in IT-Security, I can handle it from a technical and conceptual point of view but don’t want to put effort into it before discussing the general idea with the maintainers. After all it should be merged into the repo…

Ping: @marguedas @ruffsl @kyrofa

kyrofa · 2020-08-28T17:01:15.792Z

Hey there @Niklas974, welcome to the community! I agree, there are certainly improvements to be made, and I think I can speak for the entire security WG when I say that we’d love the help.

You mention that you have a background in security, but it’s unclear how familiar you are with ROS 2 in general so I’ll try not to make any assumptions. Are you already familiar with DDS-Security? If not, this design doc will probably be a helpful place to start, followed by the spec. You’ll note that we’re a little limited by the union of “things allowed under the spec” and “things supported by each tier 1 vendor”. For example, I’m not sure that all vendors check a CRL, so revocation could be a bit of an issue. Consider that not all robots are online, as well, so what happens if you can’t reach the CRL? Additionally, I’m not sure how deep you can chain (consider parameter size limits). Some examples of the challenges (and experiments needing to happen), here.

Perhaps a design doc of what you envision (or a proposed modification of the above linked design doc) is the best place to start? We can get you on the agenda for the next security WG meeting as well if you like (happening on the 8th, see the security WG community page for details on how to get the calendar events as well as a link to our Matrix room).