Going to important conferences tends to concentrate the mind on what you want to talk about and what you want to demonstrate. This was definitely the case with the recent ARM TechCon in sunny Santa Clara. My team has been very busy working with our IoT security products during 2017, and we were really excited when we managed to finalise a really exciting demo just in time to show it at the conference.
The cool thing about this demo was that we showed how to use our well-proven Root of Trust (RoT) injection, that we’ve repeated well over a billion times in smart phones, in a new environment: the micro controller space. Using this RoT, we have an established trust anchor in the device which can be used to sign things. At any later date, this can then be attested by a remote entity… and this is what underpins the demo that we showed. Our demo showed a secure thermometer enrolling with its OEM cloud for the first time and then pushing sensor data to it, with the services being hosted by Amazon Web Services (AWS).
Before I describe the demo, it is worth emphasising that the RoT is typically generated in a factory, although for this demo, that step was merely simulated. The demo begins with the device being powered on for the first time and it creates a Certificate Signing Request (CSR), which the device subsequently signs with the RoT key it possesses. The CSR is needed because AWS uses MQTT for communication with edge nodes and requires that the edge devices are enrolled with the AWS X.509 PKI. For this reason, the device needs a client certificate for the TLS communication.
The signed CSR is then transmitted to AWS for an enrolment request with the fictional OEM’s Virtual Private Cloud (VPC). The OEM’s VPC forwards this signed statement to a Trustonic VPC (which hosts records [public statements] of all created devices), for device attestation purposes. The Trustonic VPC validates the RoT-signed CSR and returns this verdict to the caller, which subsequently asks for the device to become enrolled. Once this has happened, the certificate is created and returned to the device, where it is stored and used for subsequent secured communication of the sensor data.
Of course, this was simply a way to demonstrate the possibilities of a secured endpoint pushing sensor data to the cloud and could equally have been a fitness tracker or similar device. The fact that the device had an injected RoT enables OEMs to be sure that devices requesting to enrol with their services are actually genuine and not emulators or counterfeit.
However, having a RoT is usually not enough. Because a legitimate OEM and a counterfeit one, both using chips from the same SiP would equally pass our device attestation checks, but fear not! We solve this using our patent pending solution we call digital holograms. Read more about it here.
And for those of you who really want to know how we did this: we used a Nuvoton M2351 board, which hosts a ARM Cortex-M23 MCU equipped with TrustZone. Because the board has TrustZone, we split the software in two parts; the normal and the secure world. For the secure world, we run our new product, Kinibi-M for all the security sensitive operations and in the normal world we used ARM’s CMSIS RTOS as our foundation.
Click here to read more about the demo.
