Hey guys,
I was wondering if there was a technical document for SROS2. I’m very much interested in what it offers and want to get to understand its inner workings. I also understand that the project currently is able to create signed certificates. How are the certificates and private keys getting saved? I was planning on using secure keystores to do that. Would something like that be valuable?
Hello @narayave,
The current way the certificates are being constructed is quite basic: via subprocess commands to openssl’s CLI. Once you exicute the create_keystore command via the SROS CLI, an api is triggered to bootstrap the openssl configuration files, then calls upon openssl command to generate the private keys, and singe the necessary public certificates.
Later, should you decide to invoke access control, the create_permission command will again use the keystore to sing governance and permission files consumed by the vendor specific middle ware to enable access control enforcement as defined in the OMG DDS-SECURITY spec.
I’m working on refactoring this to use something like a modern python library such as cryptography to more pragmatically control the key generation and signing of certificate authorities, like I did for SROS1. Last year I did spend a brief amount of time exploring more rigorous keystore solutions, such as open source projects like Vault:
However, in the end I figured most end users would not enjoy installing and learning a host of other dependencies and frameworks, and would more likely impeded the ease of use and adoption of SROS. So I went with the simple method of optionally ciphering the private keys to disk. Most PKI frameworks support loading ciphered keys via secrets that can be supplied at runtime, as used in SROS1 here. End users can easily take additional steps from there to guard private keys via additional custom solutions if need be.
What secure keystores methods where you looking at? It would still be nice if we could design SROS2 to interoperate easily with other 3rd party keystores methods.
1 Like
In all honesty, I’m still in the process of figuring it out. My idea was creating a package that would help users make use of a TPM to secure the certificates and keys. This work is meant to go towards my Master’s research.
Once again, this is just an idea and hasn’t fully taken shape yet.
I have another question for the SROS2, you know, the SROS supports AppArmor, why is it dropped from the SROS2 ? is it not necessary to protect from the system level now from your perspective ? thank you !
@Roser Thanks for your interest in SROS and SROS2.
The development of SROS2 has been focused on the communication security rather than the system security so far. I wouldn’t say that system-security is “dropped” but rather “not implemented” yet.
As you may know ROS2 targets a wider variety of platforms (non-Linux or non-posix) and applications than ROS1. Currently SROS2 has been geared towards providing secure communication at the lowest level of the ros client library (rcl) to allow users to leverage it regardless of the programming language, platform or implementation of the communication protocol. Currently we test on Ubuntu, MacOS and Windows, in C++ and Python, and with eProsima’s FastRTPS and RTI’s Connext.
We haven’t yet looked into the best way to interface system security tools to the current SROS2 implementation but we definitely want to do it in the future. Given that it is pretty orthogonal to the encryption of the communication it can be addressed separately. While Apparmor is awesome, it is Linux only and thus will target only one of our supported platforms. Ideally SROS2 will provide a way to define the permissions of your application in a platforms-agnostic manner and be extensible to implement generators that will provide “configuration files” or “profiles” according to the tool or platform you want to use. And the tool on Linux can very well be AppArmor.
As @marguedas well put it, AppArmor support has not necessarily been dropped from SROS2, but rather not yet implemented. My present focus has been integrating ROS2 with DDS Security, and have not yet had time to expand upon the apparmor profile to support ROS2. Another reason is that I haven’t yet surveyed ROS2’s installation structure yet, as the majority of the apparmor profile library for ROS1 helps users to author profiles of there own by abstracting the ROS1 file directory layout.
However, as mentioned before, apparmor support is somewhat orthogonal to SROS2 interrogation with DDS Security, and so could be developed in parallel. I would certainly invite contributions and pull requests from the rest of the community to add support for ROS2, or help review what currently exists for ROS1.
1 Like
Hmm… What literature have you found on the subject of Trusted Platform Module and robotics? I do like the idea of having the private credentials used for SROS2 isolated from the host OS, but that may require coding 3’rd party plugin, as the default DDS crypto plugin must load the private key from a path on disk, or serialized PEM string.
Funny you should mention TPM though, as last week or so when I was at the RoboCub 2017 Symposium, I met a PhD student, Sarah Haas from Graz University of Technology, who was presenting work on a similar topic:
Secure Authentication for Industrial Mobile Robots using Biometric Data
You may want to investigate the lab Sarah is from. I recall some of Sara’s peers working on using TPM for the Diffie-Hellman key exchange and establish a symmetric session key without revealing the private key to the network host.
@marguedas @ruffsl thanks for your infomation, let me have an basic gap/work evaluation to implement the AppArmor to SROS2 and I may try to enable that if no conflicts after evaluation 
It seems that this solution focus more on external authentication to an IMR(Industrial Mobile Robot), you know, now the ROS nodes can employ the key/certificate produced using SROS2 to authenticate/encrypt/access control for the nodes/topics etc, but do you think it’s necessary to provide the security to the key/certificate itself ? now they’re placed on the disk without any protection, that means it’s easy to be accessed or tampered.
BTW, you know more details regarding the details of SROS2 implementation, so could u please help double confirm/clarify the following questions:
- Keystore: does it support key exchange between publisher / subscriber, etc? Can keystore be changed?
- Encryption of data AES-GCM-GMAC: used to have license issue on GCM, has its license model been changed?
- Tools to create keystore, certificates: are they out-of-band tool that user needs to use this tool to create keystore manually first then pass it to DDS? How does the whole solution work?
- Is there any access control for SROS2: tools, encryption, etc?
Many thanks
BRs