This blog post dives into the new Kinibi-520a, the 2021 version of Trustonic’s Trusted Execution Environment (TEE). Like every year, this version brings new features and improved quality to our silicon and OEM partners. The main feature of Kinibi-520a is the support of MISRA-C for the TEE and the SDK. Additional features include added code protection mechanisms (PAC, BTI, ASLR+), support the latest ARM hardware features (SMC64, CCIDX), pthread support for secure drivers, new crypto algorithms (SHA3, Ed448, SM2, SM3, SM4) and better debug support (stack trace).

Introducing SMP

Since Kinibi-500, Kinibi supports 64-bit and Symmetric-Multi-Processing (SMP). Kinibi-520 completes the SMP feature by providing the Posix thread library (pthreads) to secure drivers. In particular, secure drivers can now use conditional variables. The support of pthreads (create, join, exit; semaphores, mutexes, conditional variables), allows SDK users to reuse existing libraries and algorithms that require pthreads. SMP increases the number of operations that can be performed in the TEE in parallel.

The main use case for SMP is biometrics, that is fingerprint and face recognition. Using Kinibi-520a, OEMs can write a fingerprint driver that retrieves the fingerprint image from the sensor. It uses multiple threads to calculate the vector, uses secure storage to retrieve the reference vectors and then performs the matching pattern, all in the secure world of the TEE.

MISRA-C

MISRA, the Motor Industry Software Reliability Association, provides “world-leading, best practice guidelines for the safe and secure application of both embedded control systems and standalone software”. Kinibi-520a is now aligned with the MISRA-C:2012 and MISRA Compliance 2020 guidelines.

Previously we’ve discussed the TEE journey towards tools-based code-security in Kinibi.

For Kinibi-520a, we use two main approaches: enforcement with compiler warnings and reporting of remaining defects with Coverity.

Kinibi, including its various internal components, is free of compiler warnings. We evaluated the impact of the various warnings on the resulting code quality and defined a policy of which warnings must be or should be activated. Having these warnings enabled ensures that future changes in the code will not reintroduce code quality regressions. We noted that the resulting code is generally easier to read, and we can thus avoid ambiguities that can lead to bugs. Ultimately, avoiding subtle bugs that might be exploited by a hacker. To help our customers and SDK partners to develop Trusted Applications and secure drivers in line with MISRA, we also export the compiler warnings policy via our SDK makefiles. Kinibi-520 SDK will push Trusted Application (TA) developers to enable multiple warnings to reach the highest code quality possible. When switching to the new API level 13, the SDK now defines 3 different warning levels: LOW, MEDIUM, HIGH. This allows TA developers to gradually increase the quality level of their TAs.

In addition to compiler warnings, we also use the Coverity MISRA checkers. In the development cycle, after compiling and testing, developers can now also install Coverity locally and do the Coverity Static Code Analysis (SAST) on their machine to fix any issues before presenting their changes for merging. We set up Coverity configuration files to define an enforcement policy and an improvement strategy. In addition to checking MISRA compliance for individual components, we can also run an analysis over the whole of Kinibi and generate various reports to share with customers for MISRA compliance.

Note also, as required by some OEMs for Android compatibility, all Kinibi components are now built with CLANG compiler toolchain.

Full 64-bit

To follow the Arm architecture, Kinibi-520 is introducing versions supporting only AArch64 execution mode, even at application level, meaning the TEE will load only 64-bit trusted apps and secure drivers. While we think this will be the only configuration that will be deployed, we still support other configurations with Kinibi-520a. Note also that new features will be available in preference for 64-bit TAs only.

We have also continued to transform our system call interface to replace 32-bit parameters with 64-bit parameters (story started with LPAE in Kinibi-300). In Kinibi-520, we now use 64-bit IPC. This change is invisible for users of Kinibi-520, but provides the basis for future Kinibi changes. Also, the secure monitor call interface for secure drivers now alternatively supports a 64-bit version with 8 registers.

Note that Kinibi-520 also supports the ARMv8.3 extended cache index, code name FEAT_CCIDX to support bigger caches. The cache logic will read the feature register and then interpret the cache size registers accordingly.

Following a customer request, we have also extended the virtual address space of a TA from 128MB to 196MB. This increases slightly the static memory consumption at boot.

Security

Below covers the new features that enhance the security of Kinibi-520a.

ALSR

While working on the virtual address space, we also increased the ASLR entropy. Previously it had been at 9-bit since Kinibi-410 but it’s now 12-bit. When combined with the brute-force protection we have had since Kinibi-510, we consider that this makes an attack of our product significantly more complicated.

PAC – Pointer Authentication Codes

First seen on the iPhone XS in 2018, ARMv8.3 PAC should finally come to Android phones next year. Consequently, it will be also supported by Kinibi-520a, which is delivered to SIPs and OEMs in preparation of next year’s mobile phones.

As according to ARM, PAC is a method of hardening code against Return-Oriented-Programming (ROP) attacks.

BTI – Branch Target Identification

Officially part of ARMv8.5, BTI will finally appear at the same time as PAC, together with the new ARMv9 chips next year.

BTI is yet another code hardening method, this time against jump-oriented-programming (JOP) attacks, where the branch/jump target is identified with a special landing pad instruction.

Both PAC and BTI insert special instructions in the program binary and hence require recompilation of customer Trusted Applications. The new SDK allows fine-grained activation of these features to allow for gradual testing and validation. We have so far noted problems with assembler code and 3rd party libraries that need adoption. Since BTI requires OS-support for the new MMU-flag, a TA must be 100% BTI compatible. The new version 1.8 of MobiConvert is required to inject the BTI flag in the TA header.

FDP_RIP – Residual Information Protection

Common Criteria defines several requirements for a secure system. The Family for user Data Protection (FDP) contains the Residual Information Protection (RIP) requirement that Kinibi supports (see the Kinibi Security Target).

Kinibi-520a improves the protection of residual information for TA data. Memory is systematically zeroed out directly after being released from a task.

Supply Chain Integrity

To provide our customers with ever increasing confidence in the integrity of the Kinibi product package, we have put in place multiple measures to prevent supply chain integrity attacks. While the package was always signed and encrypted and delivered via a secure channel, it now also contains sha256 checksums for individual files. Less visible to our customers, we also adopted signed git commits and validated checksums for dependencies like toolchains. Proof of these measures will be available soon on completion of the on-going audit.

New SDK Features

The Kinibi API level is increased to 13. The newly available features include the pthread APIs, new Crypto algorithms and the warning levels as detailed above.

Cryptography

Kinibi-520a follows the GlobalPlatform Standard evolution and extends the list of supported crypto algorithms to be aligned on the recommendations in the GP Internal API 1.3:

• New hashes: SHA3, Keccak, Shake
• New key exchange algorithms: HKDF (RFC 5869), X448
• New Elliptic Curves for digital signatures: Ed448 and Ed448ph
• Chinese algorithms SM2, SM3, SM4 (similar to EC, SHA2, AES)

It means Kinibi is well positioned to support Trusted Applications in the Chinese and US markets that follow recent national algorithmic requirements.

Debuggability – Stack Trace

Each Kinibi version brings improvements for TA developers to ease debugging of their Trusted Applications. In the past, Kinibi would show the register dump of a TA that crashed. Using the LR, IP and SP registers, together with the TA binary and the ASLR offsets, developers could analyze the possible reason of the TA crash.

Starting from Kinibi-520a, Kinibi will now also show the addresses and function names of the call stack that lead to the crash of the TA. The feature includes several configuration options with safe defaults to ensure that no unnecessary debug information remains in release TAs for production. MobiConvert 1.8 will now optionally inject the TA symbol information into the TA binary. If the TA has no symbol table, the crash or panic dump will only show the addresses of the functions. Note that Kinibi fixes up the ASLR bias in the printed addresses.

Summary

This blog post covers the 2021 edition of Trustonic’s TEE Kinibi-520a. The new features bring enhanced security and debuggability, as well as support for the latest ARM architectures and MISRA policies. Trustonic is working with silicon provider partners to integrate this version so OEMs can build devices with Kinibi-520a next year.