Raspberry Pi + ATECC608: Part 1 – Overcoming Modern IoT Security Challenges

TLDR: Microchip’s ATECC608 is an awesome solution to the ever-increasing cybersecurity issues in the IoT space. It solves not just the issue of securing IoT communications but also simplifies the very act of producing secure devices at scale.

You are not here for the summary, are you? Read on!

I have been working on Microchip’s ATECC608 Trust chips for some time now. Most of my previous work experience has been on microcontroller-based systems that make use of security chips in IoT end nodes connecting directly to a cloud (say AWS IoT or MS Azure IoT) or in nodes that connect indirectly to the cloud (through a gateway or something).

Recently, I decided to dive into what an ATECC608 Trust chip can do for a linux-based system like a Raspberry Pi in terms of adding security to IoT communication, reducing software burden, etc. And I was amazed at what I found!

What is the Microchip ATECC608?

Simply put, the Microchip ATECC608 is a companion IC that contains a cryptographic engine, secure key storage memory, a true random number generator and I2C slave logic using which you can talk to it. There are some quirky features like the ability to perform I2C bus obfuscation using an encrypted read/write and a built-in secure-boot command that allows a boot-loader on the host to authenticate the application before jumping to it. Handy!

As the name indicates, this is a chip that supports ECC (Elliptic Curve Cryptography). The curve supported is the well-known and accepted ECC P256 or secp256r1 as it is more popularly known (openssl calls it prime256v1 as well). But, that’s not all. It also contains a very capable SHA256 engine that can be used to do MAC and HMAC operations using dedicated commands. Finally, it packs in an AES-128 engine that supports ECB and GCM modes – not as feature rich as some other products on the market but definitely not a slouch by any imagination.

Why Even Use a Hardware Security Chip?

The primary use-case of such a chip is to store and use the private key and the device certificate required for connecting securely to the cloud of your choice (AWS IoT or MS Azure, etc.). This is considered a much better solution than downloading and storing keys from the cloud portal directly into your linux filesystem as .pem files. In fact, use of such chips is recommended by international bodies like ENISA and GSMA for enhancing IoT security. The fact that cloud vendors like AWS and Microsoft Azure also advocate this should not be taken lightly.

Moreover, some day when you deploy the product in volumes, you would need a way to get a unique key into each system without spending precious minutes on the production floor to inject unique keys and certificates. Don’t even get me started on the security risks on the production floor by the way! ☠

What are Microchip ATECC608 Trust chips?

This is where it gets interesting. It seems someone in Microchip did their homework and realized that the IoT industry’s security needs can be clearly demarcated into three categories as below.

• The it-should-just-work category – Most small-sized companies, makers, creators and hobbyists (me!) would fall into this category. The effort to do the grunt work i.e. securely onboarding IoT identities (device certificates, trusted certificates, etc.) should be minimal.
• The it-should-support-my-certificates category – Most medium-sized companies and those looking to experiment with their own cloud setups would fall into this category.
• The bob-the-builder category – These are the giants that have the time, the resources and the people to dig into the chip, work with Microchip folks directly and make their own configuration. I have no idea why someone would do this considering the second category exists – but yeah, its there if you want it.

The below table illustrates which chip would suit which category and why.

Category – Chip	ATECC608-TNGTLS	ATECC608-TFLXTLS	ATECC608-TCSM
It-should-just-work	✅ The device and intermediate certs are already inside the chip when you buy it	✅ The device and intermediate certs are already inside the chip when you buy it (but only for proto chips)	❌ The chip needs to be configured and provisioned by you
It-should-support-my-certificates	❌ You cannot change the certs	✅ You can change the certs to yours during evaluation	✅ You can do whatever you want with this chip
Bob-the-builder	❌ There is not much you can change in the chip	✅ You can add your own certs, secure boot key and so on	✅ You can make your own configuration, customise keys.. go crazy!

All the trust chips above are based on the exact same hardware – the Microchip ATECC608 chip. They differ only in their capabilities to support different security use-cases as mentioned below. Neat, isn’t it?

A Comparison of ATECC608 Trust chips

Here’s a high-level comparison of the three ATECC608 Trust variants. The best part is that these are completely hardware and software compatible (minimal cosmetic changes) – so migration is a breeze… if you ever do migrate!

Feature/Trust variant	Trust&GO (TNGTLS)	TrustFLEX (TFLXTLS)	TrustCUSTOM (TCSM)
Development time	✅✅ Lowest	✅ Low	❌ High
Configurability of device	❌ Not possible	✅ Flexible	✅✅ Fully configurable
Configurability of keys and certs	❌ Not possible	✅ Flexible but can’t change the number of keys	✅✅ Fully configurable settings including number of keys
Device private Key and certs present in the chip?	✅✅ Yes… you are restricted to using these only	✅✅ Yes… can support custom certificates as well	❌ The chip is blank when shipped to you for development
Secure Boot Support	❌ No support for secure boot key	✅ Secure boot key can be configured at a particular slot	✅✅ Secure boot key can be configured at any slot
I2C Line Obfuscation	❌ No support for line obfuscation	✅ IO protection key can be configured at a particular slot	✅✅ IO protection key can be configured at any slot

I belong to the first category – it should just work and I should be able to get my device online quickly. Hence, I would highly recommend buying a few ATECC608-TNGTLS chips whenever they are back in stock.

ATECC608 – Development Approaches on a Linux Machine (eg: Raspberry Pi)

The most important software required to work with the ATECC608 chip is called cryptoauthlib. It is a free and open-source software package available as a git repo on github. It is developed and maintained by Microchip. It is a relatively clean and well-layered piece of software that can be ported on something as low-end as an 8-bit microcontroller (this amazing board) and something as high-end as a Raspberry Pi or even an Android machine for that matter.

There are two main methods of development which can be adopted.

• Using cryptoauthlib API directly – This method gives you maximum control as a developer. You can call the API directly.
  For example: you can call a signature or a verify API from within the application. This is a common approach on microcontroller-based systems. But, as I found out by experience on RPi – not a great idea on a linux-based system due to the layered nature of linux itself!
• Using cryptoauthlib as a PKCS11 provider – PKCS#11 is an industry standard that defines a protocol called the cryptoki. This standardises the way a host talks to a cryptography hardware like an HSM, smart card or a secure element like the ATECC608.
  Microchip has done a neat job of providing all the software you would need on top of the cryptoauthlib that would make it an easily usable PKCS#11 hardware engine.

There are tons of resources available online that talk about using the cryptoauthlib API directly from within an application. In the coming sections, I will talk about getting started with the PKCS#11 approach.

But before that, let us look at how to get the software and the various dependencies involved in setting up the whole thing.

Software Installation on Raspberry Pi running Buster (should apply to others)

Although the process below has been tested on Buster (32-bit), one can assume it largely remains same for past and future releases as well.

Obtaining cryptoauthlib

Cryptoauthlib can be obtained from MicrochipTech’s github repo by downloading a release (.zip) or by using git. It is a good practice to work with a release tag rather than the master that continually sees commits. Here, we use tag v3.3.3 which is the latest at the time of writing this post.

$ git clone https://github.com/MicrochipTech/cryptoauthlib
$ cd cryptoauthlib
$ git checkout v3.3.3

Obtaining libp11

libp11 provides a higher-level (compared to the PKCS#11 library) interface to access PKCS#11 objects. It is designed to integrate with applications that use OpenSSL. Now, you can see why this method is preferable for linux systems. Most linux systems use OpenSSL – and libp11 simplifies the OpenSSL ⇄ PKCS#11 engine connection!

You can obtain libp11 using the below process.

$ git clone https://github.com/OpenSC/libp11

Obtaining pre-requisites (packages)

During the build of cryptoauthlib, libp11 and their subsequent usage, you will need several packages. It is a good idea to install all of them in one go beforehand.

$ sudo apt update
$ sudo apt install cmake cmake-qt-gui openssl libssl-dev libengine-pkcs11-openssl1.1 autoconf libtool gnutls-bin

Building and installing cryptoauthlib

Building the cryptoauthlib is pretty straightforward. I prefer using the cmake-gui to work with CMake projects but you can choose to stick to the command-line if that is your thing.

Following the process below to build and install cryptoauthlib.

Preparing a cmake build directory inside cryptoauthlib

Navigate to cryptoauthlib root directory.

$ cd cryptoauthlib

Create a directory to hold cmake outputs and navigate into it.

$ mkdir my-cal-build
$ cd my-cal-build

Launch the cmake-gui.

$ cmake-gui &

CMake configuration

In the cmake gui, provide the path to your cryptoauthlib source code and the build directory we created above to hold the cmake outputs as shown below.

Click on the Configure button. Once you do that, you should see a number of CMake switches already turned on. Leave those untouched. Additionally, enable the below switches.

Now, click Configure and then Generate.

Building cryptoauthlib

You should now see cmake outputs inside the my-cal-build directory. To build the cryptoauthlib, simply execute make.

$ make

You should now see build output that ends like below.

...
...

[ 96%] Building C object lib/CMakeFiles/cryptoauth.dir/pkcs11/pkcs11_slot.c.o
[ 97%] Building C object lib/CMakeFiles/cryptoauth.dir/pkcs11/pkcs11_token.c.o
[ 98%] Building C object lib/CMakeFiles/cryptoauth.dir/pkcs11/pkcs11_util.c.o
[100%] Linking C shared library libcryptoauth.so
[100%] Built target cryptoauth

Installing cryptoauthlib

The build is complete. To install the cryptoauthlib, simply install as elevated user as shown below.

$ sudo make install

Do not skip this step! The installation shall come in handy later as we will write applications in the coming post that use the installed headers and configurations.

Building and installing libp11

Navigate to the libp11 folder and execute the below commands to build and install. This requires no configuration steps other than executing the configuration script already inside the repo.

$ cd libp11
$ ./bootstrap
$ ./configure
$ make
$ sudo make install

Summary

In this rather long post, we learnt about Microchip’s ATECC608 Trust chips, their benefits and which one would suit whom. We also learnt how to install the software required for using these chips on a linux system like a Raspberry Pi.

In the next post, we take this further by testing that our PKCS#11 integration went well and see how we can do authenticated MQTT with AWS IoT Core using this chip. See you!