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.