I’m from arm. I’d like to share our enhancement of ROS2 and DDS security based on arm platforms.
In arm V7/V8 core architecture, we have TrustZone support (please take a look at this link) which can enhance the DDS Security Plugins currently implemented based on OpenSSL.
Through the use of arm TrustZone feature, we can switch the system execution states into:
• a Normal World (rich OS environment is executing here) and
• a physically isolated Secure World (here a trusted OS is running which protects many ROS2 security assets, like root keys through hardware protection).
As shown in below figure, the ROS2 runs in Normal World (Non Trusted) and the security assets are protected in Secure World (Trusted). Since Secure World is physically isolated from Normal World, the Secure World can protect the ROS2/DDS sensitive security assets from leakage to Normal World even if Normal World is hacked.
In contrast, since OpenSSL runs in Normal World which is not considered as trusted, the security assets in OpenSSL might be vulnerable if rich OS or applications are hacked.
With arm TrustZone, ROS2 with DDS security can run on billions of arm devices in an enhanced security environment.
We are very glad to discuss with you in details. Looking forward to hearing from you.
Hi @davidhuziji! This is certainly interesting for those of us trying to make use of ROS 2 in real applications.
Are you guys currently working into integrating these enhancements in any specific DDS implementation? Is there any working example available that we can review? Will you open source these “improvements” in an open source DDS implementation together with the security plugins as a reference guide?. This will definitely help the community (and vendors) evaluate it and eventually adopt it.
I’m particularly interested in examples working with lead DDS vendors such as RTI. Any plans on this regard?
We are currently developing our secure libraries based on arm TrustZone to support some popular DDS, together with the lead DDS vendors.
We will definitely release the implementations after it is verified, thus billions of arm platforms with ROS2/DDS can benefit from it.
Honestly, there is no “absolute” secure. It’s just about the cost(complexity) to crack.
For the CLKSCREW issue:
You can see the first step is to crack kernel in which case no secret can be kept for openssl solution.
And this attack is HW design specific.
e.g. The fundamental is that non-secure SW can control the regulators of clock and voltage.
This might not be true for all the platforms. As I know, some designs are using an MCU running in the secure world to access the regulators which are also in the secure world. The Kernel in the non-secure world can’t access these regulators directly. It can just send the high-level requests to this secure MCU through Arm-TrustedFirmware. So this MCU is a safeguard to restrict the range of frequencies and voltages that can be configured.
Another example is to use the hardware crypto engine to generate/store the keys and decryption/encryption also happen in HW. In this case, CLKSCREW can’t attack it anyway.
Thanks @davidhuziji for posting this.
Is it possible to share the more details about the design and the API that the DDS Security plugins should implement to be able to leverage TrustZone?
Hi @marguedas, we are very glad to share our design. Any suggestion is welcomed.
Please help check the two documents in below. Security Services for DDS Security Plugins.pdf (1.3 MB) introduces the general idea of our design. A group of generic internal security APIs is inserted to connect vendor DDS Security Plugins and diverse security implementations, such as OpenSSL or OP-TEE based on arm TrustZone. DDS Security Plugins Internal API specification.pdf (2.1 MB) introduces the generic internal security APIs in details.
thanks @davidhuziji!
I think several members of the community will be interested in having a closer look at these documents.
Getting feedback from DDS experts such as @Jaime_Martin_Losa, @GerardoPardo and @kydos would be extremely valuable. Moving towards adoption and support for Trustzone in all supported DDS implementations would be really awesome!
Just started reviewing the material. Looks promising so far. Just want to get some clarification on overall design.
ARM DDS SecureLib defines an interface library but does not appear to be responsible for context / resource management. For a prospective deployment context, it is possible there could exist different levels of applications attempting to leverage TrustZone, thus a form of resource management that can properly handle the context switching securely would need to be supported.
I am assuming that this form of feature would likely be presented in the TEECLibrary existing in layer EL1 in the Block Diagram on Cortex-A Platforms due to context awareness or is this something that is being attempted to be pushed into the Secure WorldTEE OS?
TEE Client library, TEE drivers and TEE-OS protect the TEE Client Application context in Non-Secure World. The context, including the resource, will be isolated and managed by TEE Client library, TEE drivers and TEE-OS.
If there is any further question, please feel free to let me know.
To give a small update on this topic: we implemented a small application in ROS2 that can be found in https://github.com/ros2-for-arm/example. This application is using TrustZone support with Optee-OS to encrypt and decrypt ROS2 messages from the application level.
As of now, this is not using the ARM DDS SecureLib (as this is still under development) but it gives a small example on how to use TrustZone+Optee-OS to secure messages by having security assets in a secure memory.
Since David’s initial post on this initiative, we have been through some different proof-of-concepts. are now finishing the design for the shape we want it to be. In parallel we have been developing the project’s skeleton with proper testing infrastructure and a Fast Model’s based development environment we will release together with the library.
We cannot give you a proper release date at the moment. The intention was to already have something released but some aspects of the investigation (finding the correct balance on what assets to move into the secure-world took longer than expected).
We are getting closer, watch this space and we promise to give an update in a month or so.
In the meantime, you haven’t seen, here is our slides from the ROSCon2018 presentation of the project:
thanks for the quick response and sharing information.
alright, i was just curious and checking status for that.
actually i was there to make presentation about “aibo” at ROSCon2018@Madrid and had a little chat with David. i think that this security extension based on platform specific backend is really good, that brings me on this thread.
As described in previous posts, the main goal of libddssec is to improve the security implementation of the DDS plugins on Arm based systems by leveraging the use of the TrustZone IP. It is based on Arm Trusted Firmware A (https://developer.trustedfirmware.org/dashboard/view/6/) and OP-TEE (https://www.op-tee.org/). Secure assets (private keys,…) are stored in a secure memory that can only be accessed by the Trusted Application. The Trusted Application is encrypted and stored into the Linux file system (under /lib/optee_armtz ). A run-time daemon (tee-supplicant) must be launch in order to load the TA into OP-TEE OS. More information can be found under the readme or doc/ folder of the libddssec project.
This initial release implements only the Authentication support.
