Kinibi-600a Commercial Release
In the mobile market, we follow the Android requirement to support FF-A and MTE – see our dedicated blog post on this matter. Trustonic is aligned with the latest version of Android (12), Linux (6.1), TF-A (2.8), Clang (12.0.1), GCC (10.3), and QEMU (7.1). CERT-C Level 1 is now enforced on all components. The robustness of our Secure Filesystem has been augmented when working with F2FS. Also, the performance of calling the TEEC_InvokeCommand API has been enhanced.
Improved Developer Experience
Kinibi-600 is now available with a QEMU-based emulator. Using our emulator, you can start a VM with a Kinibi-600 and a Yocto Linux inside. You can install your Trusted Applications and Client Applications (TAs and CAs) using shared folders in QEMU. From the Linux serial console, you can then run your Client Applications (CAs) to create a connection to the TEE and to your TA. This allows for accelerated TA development for everyone. Our experts have even been known to attach GDB to TAs running inside QEMU.
Note that ARMv9 Memory-Tagging Extension, Pointer-Authentication-Codes and Branch-Target-Identification features are activated on QEMU and help the TA developer find bugs during development.
Kinibi-600 includes, by default, a Memory Profiler for Trusted Applications. When a TA finishes, the Memory Profiler shows if the TA has any memory leaks from omitted TEE_Free. A TA can also ask to print the heap usage, so that a TA developer can see how many allocations were made in the TA, and which function allocated each buffer.
Kinibi-600 also supports extendable stacks. A TA starts always with 4KB of stack, and the stack is further extended when the TA requires more memory.
Crypto agility and security
In Kinibi-600, OEMs can sign Trusted Applications with Ed25519 elliptic curves, in addition to RSA. This modern algorithm has become an industry standard because of its simplicity, improved performance, and security properties. Trustonic is also evaluating the use of Post-Quantum Cryptography in the TEE space.
Kinibi-600 includes improved warnings mechanisms. The signing machinery now warns against insecure default keys. Also, more compiler warnings are shown when compiling a TA, but without causing the build to fail.
A number of less secure options have been removed and, at the same time, hardened the responses of the TEE against invalid commands.
Kinibi-600 supports the latest versions of ecosystem software. We now also have official support for Grub, Uboot, Xen and Ubuntu 22.04.
To support Digital Rights Management’s requirements on secure time, our Kinibi integration kit now comes with a reference Real-Time Clock (RTC) Driver and associated secure-time-provisioning API.
We have also vamped-up our RPMB driver to include the secure protocol with the RPMB hardware.
Finally, to support future TEE use-cases, we now provide a sample Flash Driver for UFS hardware. That way, the TEE can directly use Flash memory at boot time, or in the case that the Main OS is not functional anymore.
As processors evolve, the place of the TEE evolves as well. Traditionally, Kinibi is a Trusted OS running inside Trustzone. With the evolution of ARMv9 and the hypervisor layer inside Trustzone, the TEE can run inside a secure virtual machine (called Secure Partition in the FF-A framework).
With virtualization in the Normal World, we first saw the adoption of two VMs that both use the TEE in the automotive sector. Since Kinibi-401, we support this with paravirtualization with Xen-like hypervisors.
Since Kinibi-600, we now also support direct virtualization, meaning that calls from each VM go directly to the TEE. This can provide speed improvements for Guest VMs that previously needed to route the TEE-requests via the Host VM. Depending on the hypervisor, minor patches may be required in the hypervisor for the SMC filtering, memory management and the interrupt generation. We will be integrating this feature with our automotive customers in the coming months.
In the Android ecosystem, we see the trend of virtualization, or, the microkernelization of the Monolithic OS. The main OS is so complex that running security and privacy sensitive use cases in it seems like a no-go. TrustZone is the traditional answer to this question, i.e. putting your use case in a Trusted Application in a TEE. However, the availability of enough RAM, CPU power and ARM processor evolution now allow for several VMs in the Normal World on Android phones. That way, each use case has its own VM. In a few years, we imagine such VMs will also use ARMv9 Confidential Compute for these VMs. In the meantime, we are also exploring ways to run the TEE in such a VM.
With the RISC-V support dawning for Android, we are also investigating usage of Kinibi on RISC-V architectures.
Kinibi-600 supports the latest technology features required for the TEE space and starts the path towards new TEE architectures. Effectively, Kinibi-600 has been integrated with our Silicon partners using the new FF-A architecture. Production has already started this summer, and we expect the first phones with Kinibi-600 to be released in the autumn timeframe. Similarly, we expect car makers to adopt Kinibi-600 because of the improvements over Kinibi-520 and Kinibi-510, and a long life for Kinibi-600!