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.
[Discourse.ros.org] [Next Generation ROS] ROS2 and DDS Security enhancement on arm platforms
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.
Hi @marguedas, we are very glad to share our design. Any suggestion is welcomed.
Please help check the two documents in below.
<a class="attachment" href="/uploads/ros/original/2X/e/e9853b8eea8a63906618a7fc04f33954335b90a1.pdf">Security Services for DDS Security Plugins.pdf</a> (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.
<a class="attachment" href="/uploads/ros/original/2X/3/3b9b4fb8e8d8178ff37daa94a8e787b2aaf4704a.pdf">DDS Security Plugins Internal API specification.pdf</a> (2.1 MB) introduces the generic internal security APIs in details.
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 World` `TEE 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.