Tigris

My latest streaming, publishing and so on has been sponsored by Tigris. They also fund my trip to GigCity Elixir where I will be doing both a keynote at the main conference and a technical talk during NervesConf.

They offer Object Storage for anyone really but particularly interesting if you run on Fly. You get CDN performance baked in. Generous free allowance.

To get started install flyctl.
Run:
fly storage create -n fnork2
There is no step 3.

Unpacking Elixir: Nerves

New post in the series. I adore Nerves and am thrilled to be working more with it. Hope this does it justice.

Blog post: Unpacking Elixir - IoT & Embedded

All my things

I made a links page just to capture all my productions and public interfaces:

https://underjord.io/links.html

Blow a fuse, blow a future

As I'm digging into embedded device security I am hit with a bit of concern. There is a tension between highly secure and reusable devices. I don't know if it unavoidable but it is certainly challenging.

The gold standard for securing an embedded device is to have secure elements on it that hold a private key for a device certificate. These are, for security reasons, very much intended to not be easy to extract the key from. And then you can use these to uniquely identify a device fairly reliably.

If you want to prevent exploitation of your devices, either because you hate openness and hacking or you hate widespread botnets in dishwashers, you might start looking at securing the boot process. For most cases this means burning a permanent certificate into some part of the hardware (in the Raspberry Pi CM4 case it is called the OTP, meaning one-time-programmable). This cert is then consulted when booting to check that the software being booted is signed by the right party and unmodified. Irrevocably tying the hardware to a signing key/certificate authority.

These steps are part of making a trusted sequence of parts that cannot be maliciously intercepted or manipulated. Whether in the service of IP law, DRM and control or preventing abuse.

For low-volume secure installations and critical industry or infrastructure use I have no real problems with a device being locked and then hard to repurpose, reuse and so on. And I don't like the idea of the security of consumer devices being a shrug of "good enough" with some obfuscation and glue either.

I guess there is a middle ground if there are ways to activate auxiliary keys for a device that removes the security but also makes it clear it can no longer be trusted. Or if the burned parts can be easily replaced.

Have you seen companies do this right? Do you have similar concerns? What balance would you strike? You can reach me on the Fediverse where I'm @lawik@fosstodon.org or by responding to this email to lars@underjord.io.

Thanks for reading. I appreciate it.