Two NervesConfs in the same year. Unheard of!

Todd Resudek has been the person behind NervesConf and ran the US one. After NervesConf US he suggested that if I (Lars Wikman) wanted to put one on in Europe where I operate I very much could. So I did. NervesConf EU tickets are on sale!

And of course that doesn't stop the US one. So now there are two :)

Now Todd doesn't currently do Nerves and has been busy with other things. So Redwire Labs will be picking up the effort. Alex McLain (amclain most everywhere) is familiar to those who've been to the meetup and is seen around the Nerves space a lot. Give him a hand by submitting your talk to the CFP.

Everything is of course a full-on collaboration. Goatmire Elixir is inspired by Gig City Elixir and we both co-locate a NervesConf. Me and Alex collaborate a fair bit. We all do this because we love meeting other people who are way too enthusiastic about the same things we are, we want to see the community and ecosystem flourish and we think there is value in meeting.

Pick whatever fits your wants and needs. There will be great line-ups, great talks and they are 4 months apart if you want to hit both :)

-L

Project updates

No major project updates. NervesHub is quite active and I just hassled our good companions about figuring out a new numbered release. A lot of things have been done with deployment orchestration and we really should go through it.

But for now, an editorial I suppose.

Nerves Security Baseline

I am working on a library (still rough, WIP-level) called ex_verity. The goal of this library is to provide good tooling and a paved path for security fundamentals that Nerves doesn't (and probably shouldn't) offer out-of-the-box. It will be as turn-key as I can make it but it is by necessity somewhat complex. Time to talk about hardware and security.

I gave a talk at NervesConf US 2024 about this prior to the library taking shape.

Securing the boot process

There is one thing that almost all commercial devices benefit from to avoid being compromised and turning against its owner. It is variously called Secure Boot, Verified Boot, Hardware-Assisted Boot and more. Fundamentally it is about verifying the code being run. Nerves does a part of securing the firmware out of the box if you are using NervesHub. It requires firmware to be signed before applying it.

Nerves also operates a read-only root filesystem which prevents a lot of possible attack patterns. There is a lot of stuff done well with Nerves, by default. The Secure Boot stuff tends to vary a fair bit per device and always requires special ceremony, usually includes irreversible changes to a device and sensitive key management. It is something that should be done with intent, not in the the first-install wizard.

The goal of Secure Boot (et.al) is to prevent an attacker from persisting a successful intrusion and preventing the system from running manipulated code. This requires a chain of trust which is usually established by locking a certificate into One-Time Programmable storage on the device and having that verify the bootloader and then you need to maintain trust from there. So the hardware supporting a signed bootloader is critical.

As a Linux-based embedded system we use dm-verity to verify our root filesystem which works perfectly with the fact that it is a read-only filesystem. It is an efficient way of preventing corrupted or tampered blocks to be read at all.

There are some devils in the details but this is supported on a lot of devices. Even the Raspberry Pi 4 and 5 series boards have a mechanism for secure boot. ex_verity's first target board is the RPi4 as I have a client that needs it.

Protecting IP & data

The significantly more challenging part is disk encryption. There is a great tool for it called dm-crypt and fwup even supports working with dm-crypt in a nice way. But you need a way to store the disk encryption secret. And here you might think "but maybe we just encrypt a SQLite database using SQL Cipher?" absolutely, it also requires a secret, a password. Where do you put the password?

We can get into that. But first I need to underscore something. This all depends on what your risk and security posture is. Many devices can do disk encryption and just store the passwords in some separate little store, unprotected and still do a very decent job of protecting their customer data. Because the threat and risk is low. But if we want to cover most of the range and have a fully defenisble approach we must hide our secrets securely.

My first impulse was NervesKey (aka. ATECC608 series). It is kind of capable of hiding secrets but has several shortcomings there. It is roughly equivalent to putting the secret on the disk in plaintext, just slightly less convenient for both you as a developer and the attacker. It can provide an obscurity-measure. The NervesKey is perfectly valid for negotiating TLS and authenticating 802.1x and such. It handles private keys nicely enough. It doesn't do symmetric secret storage terribly well though.

A TPM 2.0 part? Well, you can put it there. Certainly. Better than on the SD card that might get joinked more easily. But fundamentally an attacker that has the device can interrogate/puppeteer the TPM. Though with the TPM you can make it a massive pain. So it depends on your needs.

The way I know of that doesn't expose your secret to some kind of divide-and-conquer attack at the hardware level is to use secret-storage built into the SoC. This is typically provided as a hardware unit within ARM TrustZone.

And that's the next step of this library. Tool up a reasonable use of ARM TrustZone to protect keys and secrets. I am looking at an iMX8-based board to implement this with a couple of clients of mine. The RPi boards have no security hardware in TrustZone so they are simply incapable of truly hiding secrets.

In closing

There is a lot of security and compliance work happening in the Elixir ecosystem in response to legislation both in the EU and US for cyber resiliency, supply chain and safety.

My hope is that we can ensure that using Nerves gives a quick and relatively painless path to what is the leading edge of securing your devices. And with the way you can switch a Nerves system without making major changes to your application we might even have the best answer for moving from an RPi to a device with a more firm security profile. There is much more to do and I look forward to figuring this stuff out.

If you work on this type of stuff as well I'd love to pick your brain or hear your notes on my thinking.

-Lars

Participating in the community

The Nerves community is found wherever Elixirists gather. Try any of the following:

Questions are best asked on the Elixir Forum.

Social conversation and banter:

• Elixir Slack, #nerves channel
• Elixir Discord, #nerves channel

How you can help Nerves

Contribute in the way that works for you:

• Send corrections or improvements for documentation wherever it fails to help you.
• Write about Nerves, give talks about Nerves. Make videos about Nerves. It is all good.
• Write or port a new hardware library and include it in the Elixir Circuits collection.
• Get in touch about taking over maintenance duties for some libraries, we might be able to provide you hardware.
• Apply for an EEF stipend on something Nerves-related and build it. We can help if you have questions about this.

Finally, if you have questions about the newsletter or want to suggest something you can simply respond to this email.

- Lars