I've been making machines do math

If you follow my stuff you might have seen mention of the work I've done with the "volatile" NervesKey config. I've also spent a bunch of time doing Raspberry Pi 4 Secure Boot. My results are in the library ex_verity but it will probably be re-architected before it goes primetime. If you need it, contact me instead of just trying to use it. Happy to put you on the right track.

I spoke about this in my talk at NervesConf US 2024 in Chattanooga.

So I keep brushing pretty closely to cryptography with this stuff. Generally using our OpenSSL-given tools (via Erlang :crypto). The volatile config work did make me poke a lot closer with the MAC and CheckMac commands that I needed to implement parts of on the Elixir side. And as part of this I kept realiziing things I didn't know.

What is Diffie-Hellman actually? I've taken it as given that we use public key cryptography for establishing the keys for TLS. We don't. Because Diffie-Hellman exists and does that job better. We use public key cryptography for verifying hosts, CAs and that. But then DH key exchange and then we have our encryption key for the transport established. If you think about this type of security stuff actually knowing the mechanics of this is very helpful and satisfying.

When I exasperatedly got sick of seeing Diffie-Hellman and just threw it at Claude to explain the answer was really good. And it seemed way too simple. So I looked it up. Checks out. Deceptively simple math.

This is actually something I'm appreciating with LLMs for exploring topics. Getting to ask pointed questions, from the direction I'm coming "I already know public key encryption, Diffie Hellman seems similar. What are the differences?" With cryptography there are a lot of high-quality write-ups of the fundamentals. They are generally long, dull and retread ground I know. But it means I can easily verify anything that seems fishy.

I've heard of the Signal "double ratchet" for years. I couldn't explain it succinctly. But if you enjoy cryptography cleverness they offer very nice detail on it. I also started that with an LLM exploration because the bite-size responses are enough to satisfy the degree to which I want to know the thing. I am very tempted to make a hobbyist-grade double ratchet library in Elixir for sport.

In my talk on the NervesKey chip I lament this unsecured I2C bus and how you can't use it for secure AES. This is still true. But due to reading up on Elliptic Curve Cryptography (EC or ECC) and Diffie-Hellman (DH) I got a much better idea of what ECDH could do for me. And the darned chip supports ECDH. It also has a mechanism for IO protection that just requires a shared key and can protect the KDF command. A shared key is a hard thing to secure. But a DH key exchange lets you make keys willy nilly. So it seems we could establish an IO protection secret with ECDH.

So what's KDF. Something that made me angry the first time I tried to understand it. I read the wrong things. A cryptographically sound KDF should be able to take one secret key and deterministically make another cryptographically sound key of a desired size. I will admit I've derived keys using ad-hoc home-cooked methods. I will try to be better.

The NervesKey chip should be able to do these things and considering what I've made it do before I'm not overly concerned about making this work. Unless the chip gets cranky with me it should be feasible.

Let's be clear. I don't understand the curves part of Elliptic Curve Cryptography. I don't follow the math. I grok the concepts, I can see how that could lead to these smaller keys and less mathematically intense calculations. But I take the implementation at face value because I don't math proper math. Diffie-Hellman was actually okay levels of math. The double ratchet is intricate enough that I have a hard time holding it in my head. Point is, this stuff is learnable too. It is a toolkit.

The really fun sport would be to see if I could make the NervesKey do all the work of the double-ratchet. Probably a variant. It essentially needs a DH mechanism and a KDF mechanism and we have those. The specific algorithms Signal have chosen might be a bit different from what the hardware can do. I haven't dug deep.

If you follow EU politics (see Chat Control 2.0 constantly rearing its ugly head) there might be good reason to keep making things more intensely hardened.

An entirely related but different rabbit hole I've poked in the past but never ended up using is OpenSSL engines and PKCS11. NervesKey uses PKCS11 for delegating the public key encryption work to the security chip. That's how I found that. And I did work to make VintageNet work with PKCS11 and 802.1x networking security. So you can auth your network based on the key in your chip. Works for both wired and wifi but I gotta tidy up those PRs to get it fully merged.

But learning about PKCS11 made me think, I wonder if this is how MacOS delegates to The Apple Secure Enclave (TM). And it turns out you can use the Apple Security chip for you. Someone put together a fun romp in two parts. It seems involved but kind of awesome.

This makes me wonder if I could make a little Nerves device strictly to be my little hardware token for my computers to use for SSH. Absolute overkill. But maybe a Pi Zero with a NervesKey on it. And then I can just a tool that connects to it over the USB gadget network. Essentially I guess I need to make a proxy for PKCS11 over the gadget connection. Or proxy the I2C directly. That'd actually be useful for more things. So many ideas..

This went long. Sorry, but not that sorry. Hope it was enjoyable. It enjoy the topic.

Thank you for reading, I appreciate it.