Commoditizing Security for ‘all connected-devices’ with 0.50$

The esp32 (IoT) board connected to a 0.50$ crypto-processor (atecc608a)

The goal— Evaluate how one could vastly improve security in any IoT project with just 0.50$. (yes, including that 10$ thing that has no business being connected to the internet.)

When you think about embedded-device security, pretty much most if not all requirements (i.e. use-cases) depend on some kind of crypto. Ex:

1. You need a unique device identity to securely — ‘authenticate your device’
2. You need to make sure the code on your device is what you expect it to be — ‘firmware validation aka secure boot’
3. You need to know that people can’t make (illegitimate) copies of your devices — ‘anti-cloning or counterfeit protection’
4. You don’t want someone stealing your IP (when in the field or the supply-chain) — ‘IP protection’
5. You want a secure way to distribute updates or communicate with a cloud backend — ‘secure FOTA or connectivity’

What do you know about Smart Credentials, J-Coin & c-lightning | Data Driven Investor

The problem:

• All of the above ultimately depends on the secrecy/safety of a cryptographic root of trust (i.e. a private key + crypto constructs/algorithms). Ok, so all you have to do is protect your keys and use standards-based crypto — how hard can that be? -right

Turns out this is a non-trivial affair, requiring solutions that can address several categories of issues such as

• Expertise: Crypto based device-security is hard
• Price: I’ve a 5$ connected thing and an HSM to secure it is more work and money than I’m willing to put in for the ROI
• Agility: It adds significantly to my dev timeframe and I need to be the first to market.
• Good enough security: The concept of good enough security — leads to things like key/certs being stored in SW (in the clear), a compromised chain of trust, an unsecured debug port or a custom SW crypto implementations susceptible to side-channel attacks.
• Complex ecosystem: Lastly, with a myriad number of silicon + firmware vendors, micro-architectures, security technologies, open source offerings, cloud platforms, and a heterogenous supply-chain comprising OEMs, contract manufacturers etc., this problem can easily get compounded, making it increasingly difficult to secure a mix of devices.

A usable answer:

‘Expertise’ is what you need to clearly understand the nitty-gritty of addressing the above issue-categories but in general, all the other issues are attributable to a much simpler knowledge-gap i.e. a lack of awareness when it comes to readily available and usable security options like crypto-processors — i.e. TPMs, secure elements, EMV chips or custom ones like apple’s T2 chip, in other words, a hardware root of trust. To elaborate on how they can drastically change your security exposure — consider this

• Price: Secure crypto processors/chips/accelerators are cheap (cost just a few cents) and most come with certifiable protection for key-storage and crypto-processing capabilities.
• Agility: Crypto-chips are available in a variety of configurations, from add-ons or isolated external modules to fully integrated secure crypto co-processors boards. So, it doesn’t matter if it’s a greenfield or brownfield project, you can still have the best of security.
• Good enough security: No need to make any more assumptions -just use the right features for the requirement. Any cryptoprocessor worth its name addresses most (or all) of basic security use-cases. Although you still need an expert to do this and not throw overloaded app developers at it.
• Complexity: Most commercially available crypto-chips are standalone modules with no micro-architectural or hardware-specific dependencies. i.e. they are pretty much MCU or MPU agnostic, requiring nothing more than a serial interface to get started. Supply-chain risks can be plugged as you can now handover pre-provisioned crypto-elements to anyone without worrying about compromise/leakage.

In short with the right expertise, crypto-processors can be a cheap, flexible, highly secure and proven piece of technology — i.e. a commodity that can accelerate security related development timescales and remove complexity -even for cheapest of devices.

So, crypto-processors: what are they?

A crypto-processor is a tamper-resistant integrated circuit (i.e. chip/microprocessor) that provides (at the very least) 2 basic functions

• Serves as high security safe for your cryptographic keys and
• Offloads crypto-related processing via hardware-based cryptographic accelerators, significantly reducing execution time and power consumption.

These chips are designed with security in mind from the ground up and come with an extensive list of anti-tampering protections (i.e. security is not bolted on to an MCU just to tick a box).

This brings us to the whole point of this blog. The other day, I happen to come across this tweet (a retweet by one of my followers — asking me what I think of it).

Hardware security features of the ESP32 are no longer usable.

This pretty much rendered the only 2 hardware-specific security features of the esp32 (a popular microcontroller for hobbyists and professionals alike) useless. A simple side-channel attack called simple power-analysis or SPA was enough to break through the secure boot, encrypted flash security features built into the esp32.

This got me wondering what-if we use a real crypto-element which comes with certified protection as the esp32's security (or crypto) co-processor instead — Is this even technically feasible, how much would it cost, how difficult would it be?

So, for my PoC, I settled on the atecc608a (0.50$) crypto-device from microchip. The goal was to put together a demo of a really simple (but typical) IoT security use-case quickly and show that price, agility, complexity are really non-problems if you want best of breed IoT security. I chose secure device authentication as my use-case.

In simple terms, I wanted to connect my esp32 to the Google’s IoT Core using a certified crypto-element as my key-store and digital signature provider.

Here’s what my set-up looked like in the end. (refer to the cover pic for a visual).

• The Esp32 is using the xtensa micro-architecture (not ARM or intel). Truth be told ‘micro-architectures’ didn't really matter, memory constraints, on the other hand, is an issue when working on a project like (yes, even for the esp32 with its 4MB flash and 520KB RAM.)
• To make things interesting, I used micropython instead of the espressif’s standard FreeRTOS. This made it a little challenging as I set out to write my own i2c driver in pure upython but later found a github repo by @damiano mazzella with all the bits I needed.
• The crypto-chip ‘atecc608a’ with a single i2c interface and a common criteria JIL rating of ‘high’ is pretty easy to work with despite not having the actual datasheet (under NDA). Its predecessor’s ‘atecc508a’ datasheet is available online and the basics are mostly the same for both.
• Google cloud IoT Core — authenticating with google’s IoT Core using the ‘JWT’ standard (realized this PoC can easily be extended to other forms of auth — like TLS mutual auth or custom auth options offered by many IoT cloud providers like AWS, Azure, Watson, etc.)

I’ve published a github repo with the code/scripts required for the demo here — https://github.com/nihalpasham/micropython_w_atecc608a_googleIotCoreAuth

PS: If you run into any hiccups, use the included jupyter notebook for guidance. For any questions on device personalization, drop a note/tweet separately @npashi

Result:

Turns out — in practical terms its cheap, quick (relatively speaking), significantly improves the level of usable security, all without the added complexity.

If all goes well and you’ve managed to get everything working, you should see the esp32’s blue led flashing every 2 seconds. Something like this.

Secure device authentication with ESP32 + micropython + atecc608a

And your google cloud account should be recording telemetry data.

Google IoT Core — subscription view of ‘test’ telemetry data

Some notes:

• Microchip’s standard library (cryptoauthlib)for interfacing with the atecc608a is available in C and python wrappers if you’re looking to try this on say an SBC running something like Linux.
• For the esp32 with micropython, I’ve extended the i2c upython driver to add secure boot (digest mode), IO protection to protect against MITM attacks on the i2c bus (still need to figure out where you can store this IO protection secret on the esp32).
• I’ve used the atecc608a but there are quite a few others — STM Micro’S STSAFE-A100 or NXP’s A71CH modules
• Typical use-cases: HW crypto wallets, or any blockchain -‘ed’ device, medical devices, consumables, DIY drones, etc.