- Getting Started
- Trusted Platform Module
- Design Partners
Trusted and Secure Authentication with ATECC608A for Google Cloud IoT Core
Why would you harden your IoT Security with the ATECC608A for Google Cloud IoT Core?
Securing communication with a Cloud service and manipulating keys comes with many challenges: storing and using keys in the microcontroller exposes them, operating systems and software have bugs, the Heartbleed bug for OpenSSL was notable by easily exposing keys. Consequently, governments and corporations across the globe are working to protect individual identities and privacy. Strong authentication is the start of robust security. This leads cloud providers to push towards hardware-based security to obtain strong device identity protection, prevent identity spoofing, but also to protect against unauthorized firmware updates and prevent proliferation.
An easy way to hack an IoT device today is to physically attack the embedded system and spoof the private key which is likely located in the clear of a microcontroller memory. But hacking a single device or transaction is typically not of value to an attacker. Hackers are looking for weaknesses that will enable them to exploit a large number of connected devices. Once the keys are spoofed, the devices are accessed, a scalable remote attack can be launched leveraging the corrupted IoT devices as entry points
Google Webinar on Security with the ATECC608a and Cloud IoT Core
Cloud IoT Core Authentication Use Case
Hardware based root of Trust for Google Cloud IoT Core
Simple to implement, flexible and agnostic
First a word on Google Cloud IoT Core. Cloud IoT Core uses Cloud Pub/Sub underneath that can aggregate dispersed device data into a single global system that integrates seamlessly with Google Cloud data analytics services.
The links in the "Getting started" tab explain how to provision the ATECC608A with Python based provisioning scripts as well as how to setup the Google Cloud IoT Core account and policies.
The advantages of such implementation are :
- The hardware is completely agnostic of the source of the TLS stack due to the usage of the JWT token
- The usage of CryptoAuthLib library enables an agnostic choice of microcontroller.
- The code size for the JWT implementation is very light (less than 10kb) and enable secure authentication on small microcontrollers when relying on the ATWINC1500 or ATWINC3400 TLS. Here, the SAMD21 (Cortex-M0+) is used.
20 Years of Experience in Secure Provisioning
Microchip is here all the way through
Trust cannot rely only on the device but also on the manufacturing process. Exploiting third party weaknesses is one of the top targets for hackers. Isolating keys and secrets from manufacturing is equally vital. Customers can leave this burden to Microchip's secure factories and leverage our trusted provisioning service already used by thousands of companies. It's zero touch, the private keys are never exposed.
In a mass production environment, a secret exchange between Microchip customer and our secure provisioning service occurs. The device certificates (last leaf) are provisioned in our secure factories using HSM (Hardware Secure Module) networks in the ATECC608A. The secure element uses the device certificate and the RNG (Random Number Generator) to generate the private key inside the device, inside the factory. The private keys are never exposed to user, manufacturing or software.
- Educate yourself about the Google Cloud IoT Core Security model for light embedded systems
- Understand why private key isolation is vital to your design
- Learn how CryptoAuthLib manipulate the JWT token
- Learn how to configure the memory zone and set your expected policies
- Learn the basics of provisioning a secure element
- All the provisioning – keys/certificates generation and manipulation is done within Microchip secure factories
- Keys are internally generated and never exposed to the outside world, it’s zero touch
- Elimination of any software or manufacturing backdoors
- The device ships pre-provisioned with the secrets