Trustonic’s main product, Trustonic Secure Platform (TSP) and Trustonic Application Protection, enable OEMs and service providers to utilise the hardware-backed protection of TrustZone for maximum security for their sensitive data and keys. We have been around for over 5 years now and our technology has already been integrated into over 2 billion devices worldwide and is now in over 50% of android device shipments. When you are successful in one area, the logical next step is often to try to replicate that success in a related or similar area.
So, my team was tasked with the intriguing challenge of seeing whether we could repeat our current success in ARM’s larger CPUs (Cortex-A, mainly used in smartphones) in the new microcontroller unit (MCU) space where ARM has recently introduced TrustZone.
Securing IoT devices is a phrase that is on everyone’s lips these days, but exactly what services are really needed?
- Device attestation – to ensure that only legitimate devices can enrol with an OEM’s cloud.
- IP Protection – to protect the sensitive IP on the MCUs from cloning and tampering
- Secure storage and crypto implementations
- Cloud enrolment (automatic enablement of devices)
However, that question is somewhat unfocused. Of course, a device needs security services for various use cases, but, more importantly, it needs to make security simple. This is the main goal with all of our products – how do we democratize security such that everyone can benefit from it without being security experts themselves?
The key thing about MCU-based devices is that they are small, slow and very, very (!) space-constrained (compared to Cortex-A systems)– so this provided us with a really intriguing challenge. For those of you who were involved in feature phones 10 years ago, this will be a familiar setup, although the biggest difference is that the devices today are always connected, which was not the case with feature phones.
A smartphone has gigahertz cores (several of them), gigabytes of RAM and gigabytes of storage. In the MCU space, we are talking about devices with perhaps 32 MHz for the main (sole) processor core, 8-16 KiB of RAM and perhaps as little as 16-32 KiB of flash for storage. Just looking at the size of our main TEE, the Kinibi-400, it was clear that it would not fit in the most constrained of MCU devices (despite modularity you are still looking at 200 KiB+ for a fully functional TEE) and so a new approach was required. What a contrast! What a challenge!
I’ll spare you all the gory details of us getting to this point, but what we finally designed is a modular system which enables OEMs to pick and choose only the parts which they need for their use cases. This is the opposite of our approach in the smartphone world, where we satisfy all possible use cases at once. So, what we have produced is a system that mimics Lego blocks; i.e. each MCU supplier chooses and builds their version of the trusted services which they need – and nothing more! And we call this our Kinibi-M.. where the “M” could stand for mini, micro, modular…. or all three simultaneously!
An OEM has only one use-case in mind when they look for a security solution and will make their version of Kinibi-M as slim as possible. However, a different OEM needs more features and thus creates a different version of Kinibi-M. The two versions of Kinibi-M will look distinctly different, but actually share some commonalities, such as device attestation and IP Protection.
But this is not all; in addition to the above, Kinibi-M also changes its features depending on where the device is within its life cycle. So, during manufacturing, one set of functionalities is needed when the SiP establishes the chip’s Root of Trust (RoT). However, when the device enrols with a cloud service for the first time, the code needed is different and it no longer needs code related to the RoT instantiation. To solve this, Kinibi-M is built in a modular fashion and disposes of modules it no longer needs when it moves from one life cycle stage to another. Equally, it can also receive new modules for other services it needs for other life cycle stages.
By having the possibility for Kinibi-M to morph depending on its life cycle stage means that it can support a wide variety of use cases and deliver more services, whilst still existing on a tiny MCU. In actual fact, the full range of required services needed for the entirety of the device’s lifetime could never fit on an MCU in any case!
