Kinibi-510a brings best-in-class TEE security

Kinibi-510 TEE next to Android and QNX

This blog post dives into the Kinibi-510a, the 2020 version of Trustonic’s Trusted Execution Environment (TEE). It has been integrated with Silicon Providers in 2021 and is now being integrated with OEMs, some having already products launched. Kinibi-510a has completed Common Criteria Certification to Evaluation Assurance Level 5+ and has the highest assured security of all TEEs in the world. It includes many new features for improved security and debuggability.


With Kinibi-500, we focused on improving performance, bringing full support for 64-bit and Symmetric-Multi-Processing (SMP) to Kinibi.

For Kinibi-510, the focus is on adding additional strong security. We integrated multiple advanced security techniques to protect Trusted Applications running on Kinibi on ARMv8 hardware. Kinibi-510 now contains brute-force attack detection mechanisms, additional heap checksums to detect more buffer overflows, and mitigates against stack-overflow and ROP-attacks. Kinibi-510 also uses privilege reduction to put a bar on Driver-based exploits.

In terms of usability and added functionality, Kinibi-510 better supports SMP drivers by supporting multithread-synchronisation APIs and also allows log-level-filtering of debug messages.

In terms of new Cryptography, Kinibi-510 added support for the Brainpool curves, Ed25519 and X25519.

Also, Kinibi-510 supports ATF 2.3 and CLANG/LLVM 9.0.

Protecting Trusted Applications

Normal Applications can attack Trusted Applications in the TEE. Kinibi-510 protects TAs and Drivers.

OEMs like to add features to their devices and to get them out to clients quickly. To enable OEMs to do so, technology providers like Trustonic need to deliver tools and components to allow OEMs to develop their own solutions. Components from Trustonic undergo extensive internal and external code reviews and we find that hackers have a hard time finding bugs in Trustonic components.

However, Trusted Applications, developed with Trustonic tools, do not always have the same level of oversight, and have been the target of hackers. In response, with Kinibi-410, we made ASLR and stack canaries the default for Trusted Applications. With Kinibi-510, we wanted to go even further.

We  surveyed recent attack methods and respective protection techniques. The major issues we saw were memory corruption, control flow redirection and privilege escalation. We went on to address those issues one by one.

Memory protection

Bugs in memory handling are a recurring problem for programs written in C and C++. All too often, stack overflows, heap overflows are synonym not only for bugs, but for attacks. In such cases, an attacker will issue a command to a Trusted Application (TA) to make it perform an action. However, in the parameters of the command, the hacker injects unexpected data. Now, if the TA has some bug (highlighting a missing security design aspect), the TA may not validate the input data and allow the hacker to write to stack or heap memory, outside of the designated buffer. Stack canaries put small random checksums at the boundaries of stack buffers. That way, the program can detect overwrites and underwrites and abort the operation to protect itself.

With Kinibi-510, we also added heap canaries. Therefore, each time you call TEE_Malloc, there is a reference value stored in the heap header that depends on a per-TA random value and the allocation context. On each TEE_Free, this value is checked, and we can hence detect heap corruptions.

In Good case, main() function calls f(), which in turn calls g(). Return addresses are stored on the stack and used at the end of the function to jump back.
Under a ROP Attack, the Stack is corrupted and the programs jumps to wrong return addresses.

Control Flow Integrity

When writing a program, you usually start with a main() function that calls other functions, which then call other functions. Once finished with a given function, the program returns to the calling function to the place where it was called. This mechanism is implemented using the so called “return pointer” or “link register”, and a series of stack frames to allow nested function calls. At a given time, the stack frames contain the various saved link registers of the functions to which the program should eventually return.

A Return-Oriented Programming (ROP) attack will now overwrite the stack frames to make the program return to other functions not foreseen by the developer. We say that the attacker redirects the control flow of the application.

The industry has provided several additional protections against ROP attacks: Shadow call stacks and Pointer-Authentication Codes (PAC, requires ARMv9).  To provide best-in-class protection on ARMv8-based processors, Kinibi-510 integrates Shadow Call stacks, also called backward-edge CFI from CLANG compiler toolchain. Trustonic supports PAC from Kinibi-520 onwards.

How does CFI work in Kinibi? Kinibi provides a shadow call stack for each Trusted Application. The CLANG compiler is instructed to store the “link register” content to the shadow call stack. Whenever the program returns from a function call, the link register is loaded from the shadow stack and not from the main stack. That way, if the attacker overwrites the main stack, the function still returns to the right place.

The Shadow Stack contains a protected copy of the function return addresses. In case of attack on the Stack, the functions can return to the correct place.

Detection of Brute-Force Attacks

To defeat random-based security, like stack canaries and ASLR, an attacker can run the same attack repeatedly, eventually guessing the correct random value. Depending on the entropy (number of bits) of the randomness, such brute force attacks can be quite fast. However, with each wrong guess, the application crashes, for example, because of a segmentation fault when accessing beyond existing memory, or when a canary corruption was detected.

With Kinibi-510, for each Trusted Application we remember when it crashes. If a TA crashes too often in a given period, we don’t allow the TA to load again until the reboot of the device.

Driver privilege reduction

As a Microkernel-based Operation System, Kinibi isolates Drivers into separate processes in SEL0, meaning they cannot program directly the processor’s system registers. To interact with the hardware, the drivers must first use controlled memory mapping interfaces to request access to the peripheral’s MMIO buffers. In previous Kinibi versions, certain memory regions were forbidden for all drivers.

From Kinibi-510, a new configuration manifest file allows the OEM to configure for each driver the list of memory regions that this driver can access. This Mandatory Access Control policy effectively prevents all future exploits where an attacker could, after first taking control of the driver, take control of other parts of the embedded system.

Attacks based on Drivers or even on insecure TEEs seem to plague the industry, and that is why ARM introduced the secure hypervisor with ARMv9. See also our article “the TEE and the Hypervisor”. In their whitepaper, ARM evaluated these issues as an impossibility to enforce the principle of least privilege. However, Kinibi-510a, with driver privilege reduction,  proves that it is possible to also isolate the Normal world from the TEE.


In this post we have outlined the security features that a best-in-class TEE needs to provide to customer in order to ensure the highest levels of protection.   By monitoring a combination of the threat landscape, the latest security research, working with standards bodies and testing houses etc. Trustonic strives to stay at the leading edge of security.   Kinibi-510a is the best TEE for ARMv8-based processors that are deployed in billions of devices every year.

For next generation ARMv9 processors, we recommend adopting Kinibi-520 which has been designed from the ground up, in close collaboration with our silicon partners, to meet the needs of this new Arm architecture.

Get in touch

Contact us to find out more

Please leave us a message and
our team will get back to you.

Oops! We could not locate your form.