We are developing security IOT solution based on TX2 TrustZone Trusty/TA supporting. A lot of security hardware assistant security feature will be enabled to harden our SDK, such as secure booting and TEE based secure storage, attestation, TFA based crypto service, key management, etc.
Based on our prior experience on other Cortex-A SoC, we will need to customize secure bootloader to enforce resource isolation and proper memory isolation between REE and TEE and also other OS BSP/components etc. Something similar to Raspberry PI3 optee customization as per Raspberry Pi 3 — OP-TEE documentation documentation.
you may refer to developer guide, Security chapter for the security features.
it’s Trusty to enable secureOS features to ensure code and data on a device is protected.
you may also download L4T Driver Package (BSP) Sources, there’re trusty_src.tbz2 and atf_src.tbz2 packages for you to build ATF and Trusty.
thanks
Thanks Jerry for the nice suggestion and will explore the information you provided.
Next immediate developing case for us is like following:
*** We are developing CMAKE based SDK cross-compiled on Linux host machine and then deploy to Jetson TX2 target.
Please help me understand what are best approach Nvidia would recommend on above developing case.
1. Cmake will need to point at target rootfs for dependancy resolving by
set(CMAKE_SYSROOT ${TARGET_FS}).
IN case, existing device rootfs missing certain library such as libssl-dev, how should I properly customize/overlay existing device rootfs by applying libssl-dev?
2. Once we done with SDK cross compiling and want to deploy all headers/executables/libraries to the target, Does Nvidia have any existing flow/scripts we could use to facilitate the deploying process?
you may refer to Kernel Customization chapter for the instructions to configure the compile environment.
moreover,
here’s flash.sh script file to perform image flash, you should also check Flashing a Specific Partition to flash a specific partition instead of flashing the whole device by using the command line switch ‑k options.
thanks
One more question, does nvidia trusty have a writable secure storage solution for L4T? I realize that It provides EKS partition for provision user secrets and but it cannot be used to store the onformation during runtime.
It can be backed by either linux file system or flash RPMB.
I also came across TLK Android document and Android solution seems using linux daemon to I/O encrypted objects to Linux fs. Can we enable same solution on L4T?
Disk encryption is for Linux REE world and once user entera correct credentials, the file system becomes transparent to Linux users.
TEE secure storage is only visible to TEE trusty TA to store or update runtime data from TA. Underneath storing can be backed by linux fs but it was encryted within TEE before writing out.
Carefully studied the Disk encryption solution you referred to me. Correct me if I got it wrong. This mainly works for the use case where privileged system process in Linux normal world could acquire passphrase from LUKS-SRV TA in secure world and then use it unlock encrypted disk partition also decrypt DEK key to access encrypted content.
My intended use case is purely aimed for our customized TA in secure world(TEE). Our customized TA wants to access secure storage so It could persist some run-time data for later I/O. Secure storage can be backed by Linux file system or Flash RPMB blocks typically. When linux file system is used, typically a normal world tee-supplicant daemon is required to service secure world TA’s RPC request to allow encrypted contents to be written into file system. Note: Contents were encrypted within secure world before it travels outside, which is encrypted by secure storage symmetric key.
a Trusted Execution Environment (TEE) to provide secure environment for running Trusted Application (TA) to protect code and data,
you may have a client application (CA) running in the non-secure environment, it typically has a trusted application (TA) in the secure world;
all secure operations are initiated by CA, TA acts as a service provider to various requests.
there’s hardware support to ensure secure resource, such as MMU, peripheral or memory is not accessed in non-secure world.
thanks
Hi Lei,
As Jerry put it, we don’t currently support secure storage for the TA under Trusty. However, we are investigating a TEE that is more naturally feasible to support TA-based secure storage in the future. Should you have any suggestion, feel free to let us know. Appreciate the sharing of your usage scenario.
Just wonder if Nvidia consider using OPTEE as an option? In that case, secure storage should be available. Anybody has tried enabling OPTEE on TX2 L4T successfully?
"Anybody has tried enabling OPTEE on TX2 L4T successfully?
=> I don’t think so but thanks for your feedback. We will look into OP-TEE as secure storage will then be available.