It is my pleasure and duty to introduce some of the companies that make Goatmire Elixir and NervesConf EU possible.

Physical access control, solved digitally.

That's the tagline. I know this company more closely as a small and fun crew of creative and dedicated nerds. One of my former colleagues work there, I work with them. They reached out to me as they were adopting Elixir for a hardware project because they wanted to ensure they were using things correctly. The work they are doing is super interesting. They are also transitioning their cloud services from Ruby to Elixir.

They do security-critical work, they provide convenient access control to shared buildings and a lot more. Their work involves everything from the cloud infrastructure and down to the electronics. This is a small team growing actively and I'd recommend anyone to talk to them.

To spell it out, they are hiring and you can get the details and apply here. Or meet them at Goatmire Elixir and have a chat.

I'm thrilled that they rolled into the Elixir community and immediately offered to sponsor an event. I've had a ton of fun working with this crew and I look forward to following their plans.

Kivra is a household name in Sweden. They provide the digital mailbox that everyone I know uses to avoid drowning in administrative paper. I'm pretty proud to have them as a sponsor. I didn't do much to earn it honestly. They reached out to me because they want to support the community. Absolutely class acts.

Kivra is one of Sweden's traditional Erlang houses and have since a bunch of years also picked up Elixir. Also big users of the Erlang database Riak (and I suppose OpenRiak now?). They have some other languages in the mix as well which you might see if you check their jobs page. They tend to be hiring, continuously but not fast. Whenever I speak to their CTO, Jens, I get a very sustainable perspective which is great to see.

Big kudos to them for giving back to their community.

Stacking bits

I've been working on the ATECC608 aka NervesKey. I'll probably make proper announcements around the new feature eventually we've released v1.4.0 of the driver library but I'm still tidying up the the NervesKey release.

Anyway. This device is pretty terrible to work on. Part of it is that the full datasheet is only officially available under NDA. This datasheet has a lot of stuff on it. And then you also have their open source implementation of a bunch of the features in cryptoauthlib. From what I've seen cryptoauthlib won't help you configure the device correctly if you are trying to do interesting stuff.

Some of this should be hard. A security device can't be too helpful. I think the NDA and obscurity is nonsense, that should all be open and thoroughly documented really. But in use the device does have to be terse and not indicate if you are close to success or miles off. In cryptography attackers often utilize things like the timing difference between almost-success and failure to figure out if they are on the right path. There is an importance in being opaque.

Most of the operations I needed are related to hashing. The critical property of cryptographic hashing is kind of that if you are a single bit off the hash is completely different. I've run into this implementing HTTP Authorization/signatures for fediverse stuff I was trying. You need to reproduce the exact same message as the other party expects. Hash it, sign it. One bit off, entirely different message and everything is wrong.

Now this might have been easier for someone who is more used to bits, bytes and datasheets. I've done some bits and bytes for StreamDeck, the VCNL4040 ambient light sensor, the ID3 library I did with Changelog. I'm not entirely new to this but I made so many goofs. The existing library didn't go very deep in these features so I didn't have implementations to reference for a lot of the stuff. And I put so many bits in the wrong order that you would not believe.

When I had the rough idea right and had ironed out a lot of the config to look correct I figured out that I was probably mostly off on how I constructed my messages for the digest calculation.

I'd confirmed that the hashes generated by the device were exactly the same as :crypto.hash(:sha256, msg) would produce. I eventually managed to confirm that my calls the Nonce command did some things correctly. Then I want the MAC command working because it was the simpler sibling of CheckMAC where I could make all the inputs deterministic. The MAC is a hashed message not much more than that but ..

These messages are weirdly structured. And a single bit off will screw you up. I found that a few of the message construction pieces were implemented in cryptoauthlib to be run on the host which is nice because you do need to do that. So I figured, I can make a comparison, see where my message is off from the (presumably) correct implementation. I'm not a C/C++ dev so doing this seemed hard. I can read C okay at this point, and C++ if it stays reasonable. But writing it would take a long time.

This is a case where I had a good use for an LLM. It could write the Makefile, the trashy project for testing and printing results and I could compare it with my Elixir code. It worked well. You can look at some of my very rough use of it here. This code is only used to verify that my code does the same thing.

I found a bunch of bits and bytes that were somehow a little bit off. At one point I'd accidentally sliced the serial number at an offset of 1 more byte than intended for example. And there were a number of these things.

I did this for the MAC command first, got it working. Then I could tackle the CheckMac that I needed and eventually I got there. Then I found further bugs in my config, burnt at least 3 more chips. But now I have it working..

Hardware is fun and challenging. Security-oriented hardware doubly so. Or maybe 1.5 times as fun and 3 times as challenging. Bit of diminishing returns.

Thanks for reading. I appreciate it.