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!