Introduction
Trustonic recently unveiled Kinibi-610a, the latest version of our Trusted Execution Environment [TEE].
While Kinibi-600 offered increased support for more platforms and environments, the new Kinibi-610a provides more system features, with the latest changes for Trusted Application [TA] developers revealed in Part One of this blog series.
In this next blog, we highlight the TEE evolutions that will most interest integration engineers in the Silicon provider and device manufacturer space.
TEE Memory management
Trusted-Execution-Environments (TEEs) run in physical memory areas, carved-out by the Trustzone address space memory controller, which are also colloquially called Firewalls.
Traditionally, the TEE started by using 64 KB, but now we see deployments with up to 100 MB. Similarly, the virtual address space available to Trusted Applications can also be quite limited, for example when a one-to-one mapping is used.
The virtual address spaces were often quite limited as well and could not use the full range offered by the processors, like 32bit or 39bit. This has a negative impact on the security of code protection techniques like ASLR, limiting it to 7bit for example, meaning only 128 attempts are needed for a brute-force attacker.
With Kinibi-610a, we reviewed the memory configuration and now configure the MMU to use a 3-level page-table for Trusted Applications, offering a total of 4GB of virtual address space. Future improvements can bring this up to 512GB if required in a customer use case.
Additionally, these changes allow us to improve the ASLR protection, going to 18 bits for TA code and 19 bits for McLib code. In addition, since Kinibi-510, attacks on ASLR are also mitigated by the Anti-brute force monitor.
Internal changes to Application loading
Simple embedded operating systems (as well as some TEEs) come bundled with their applications in a single packaged binary. In contrast, Kinibi allows loading application binaries from the outside, allowing independent firmware update flows and software life cycles. However, Trusted Application binaries must of course be signed by the device maker or OEM.
As use cases and TA deployment usages have evolved, we felt it necessary to align our TA-loading-from-REE architecture.
The new architecture allows more efficient Open Session operations in the case where a TA is embedded in the TEE or already loaded (keepAlive). Also, prior limitations on TA-to-TA communications are now removed, since a calling TA can open a session to a TA UUID, and the TEE will automatically start up the requested server TA, if it can find the UUID in the REE side.
The new TAFileServer component implements this new functionality.
TEE Logging in syslog
In addition, Kinibi-610a now allows redirecting TEE logs to syslogd on Linux-based systems. This aligns our Linux integration with Android, where TEE logs are available in logcat, for several years. Previously, Android copied the Linux kernel logs from dmesg to logcat.
With Kinibi-610a, a new, optional, TEE LogServer in our user-space Daemon now provides the TEE logs to either syslog or logcat. As soon as the LogServer connects to the TEE, the TEE stops sending its logs to dmesg. This new architecture helps with problem analysis in platforms where dmesg is not available for application debugging.
Encrypted logs
Active debug code (CWE-489) and Improper Management of Sensitive Trace Data (CWE-1332) are common weaknesses that device manufacturers face. Trustonic’s default policy is to eliminate the traces in the production version of the TEE and Trusted Applications.
With Kinibi-610a, we now also support encrypted logging. That way, sensitive TEE logs are obfuscated from an attacker that cannot understand them anymore. This allows device makers to temporarily increase the active debug code in their Trusted Applications to do a form of in-field debugging. The TEE LogServer can store the encrypted TEE logs on the device. The device maker can modify the TEE LogServer to send the encrypted logs to the device makers’ server for analysis.
To use encrypted logging, the device manufacturer must enable the TEE LogServer and inject a public key into the TEE image. Using the private key, the device manufacturer can then decrypt the encrypted logs sent by the device.
Application signing with python3
With Kinibi-610a, we have also made the transition to python3 by updating all our internal and customer tools. At the same time, we also abandoned java for customer tools and now deliver only python scripts in source code, thus giving our customers some freedom to extend these tools.
The new tool taBuilder.py provides the same functionality as MobiConvert.jar and has an equivalent command line.
Kinibi-610a has improved capabilities and new features
Overall, we have detailed how the new Kinibi-610a system features and capabilities are most relevant for Silicon provider and device manufacturer integrators. In the next part of this blog series, we will give an outlook about future work and early access features of Kinibi-610a.
