Secure elements, beyond TLS

Another one where me and @fhunleth have gone kind of deep on a topic and I figure this information should be in the community. Findable.

So NervesKey is a cool library for setting up device certificates and via nerves_key_pkcs11 it allows us to override what OpenSSL uses for particular connections and suddenly we can have a high degree of certainty about which device is connecting. This works for NervesHub and other IoT cloud things. TLS with device certificates without unduly findable provate keys is fantastic.

This uses the Microchip ATECC508/ATECC608A/ATECC608B series. Interestingly the 608 chips can also hide secrets for symmetric encryption. Sweet. Suddenly a world opens. Hide your SQLite encryption key, you disk encryption key, key to your journal.

Not quite. Signatures are not secret, authenticity is “easier” than secrecy. In the midst of my excitement Frank noted that the darned thing ships decrypted secreta over a slow, plain I2C bus. So it is physically exposed at the time of decryption, travelling to the SoC.

I have been digging for options for my client REDACTED. We can probably physically secure the unit with tamper protection to mitigate the I2C bus being exposed but a deeper protection would be nice.

Beyond the plaintext transport the ATECC chips have been hit with some novel laser fault injection hacks, that while risky and kind of demanding, have potentially real implications to the security of the device.

Currently I’ve seen NXP EdgeLock, either in the iMX9-series, iMX8ULP devices or standalone via SE050 chip. I am sure there are others I am not aware of, these bill themselves as a Secure Enclave.

The other interesting angle is ARM TrustZone plus OP-TEE which lets parts of an SoC run trusted code only and allows the designer to include certain hardware only in the trusted part. This enables heavier security in terms of hiding secrets.

All of these approaches should typically allow interop with OpenSSL to get stuff done.

I would love to push this forward as my work progresses specifically for Nerves and I am curious if others have done it or have hardware recommendations.

5 Likes

I am travelling now but at home I apparently have a bundle of these waiting for me. The NXP EdgeLock TM SE050. Will see if I get a chance to do something with it.

1 Like

SE050 datasheet

“Support for SCP03 protocol (bus encryption and encrypted credential injection) to securely bind the host with
the secure element”
more on SCP03

Finding details for this? Probably in an “Application note” somewhere :smiley:

1 Like

It looks like NXP published an app note about how to bind a host to the device here.

Section 2.1 has a link to the SCP protocol spec sheet, which seems to want to collect your email before you can view it.

This is a very dense data sheet and I’m pretty sure you’re aware, but I want to point out two of the functions/operating modes because it wasn’t immediately clear to me: It has 50kb secure onboard storage for encryption keys and such, so it would be a secure replacement to the ATECC line of chips used by Nerves Key.

But also has a secondary function (which was my first impression of the chip does when I read the data sheet) to add a semi-secure bridge between a controller and a sensor or storage chip. You could theoretically store your keys in the ATECC chips, and use the SE050 to create an encrypted channel of communication, but which is still plaintext on the ATECC side of things. This doesn’t really get you anywhere in terms of security, as you’d still have plaintext keys on an I2C bus (just not one that is talking with the host device), plus the other security considerations of the ATECC chips you mentioned above.

The only reason I can think of for why they have this functionality is for hosts with just one I2C controller to be able have encrypted bus communications while still supporting reads and writes of traditional I2C sensors which don’t need encryption.

In terms of implementation, I’d be willing to bet there is a NXP provided implementation which might be possible to repackage into a NIF. More fun in Elixir land though :smiley:

If you make any progress on supporting the chip please post updates, I’m curious to follow along!

1 Like

Will dig into that when I get a moment :slight_smile:

Yeah, so it seems like it would cover all the ground the ATECC chips cover but also seems to have a way to encrypt the transport. It also has a lot of other features that may or may not be necessary. From what I can tell the ATECC is essentially unnecessary with this.

Their SDK stuff includes a PKCS11 module so you can hook it into OpenSSL directly.

And while I’d prefer to implement support for it from Elixir, as you say, there is an implementation. The fast path is probably to lean on their implementation initially.

I’m quite curious about the support for NFC-ish powering and provisioning. Being able to provision/program devices by blooping a device to them seems wild. Not important to what I’m currently up to but interesting.

I didn’t dig into that extra I2C functionality, also not clear how running a sensor in plaintext via a secure chip is any more secure than running it directly :slight_smile:

Right now I’m travelling and these samples just arrived at home. Near term I don’t have license (read someone paying me) to run a lab on them. Will report more when I do :slight_smile:

1 Like