Nihal Pasham

Nov 19, 2019

6 min read

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.)

  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’

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
  • 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:

  • 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?

  • 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.
Hardware security features of the ESP32 are no longer usable.

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.

  • 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.)


Secure device authentication with ESP32 + micropython + atecc608a
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.