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

Ampere and GleSYS are partnering as founding sponsors of Goatmire Elixir. I've collaborated with GleSYS before and I find we hold very similar values. I've been curious about Ampere's products and I finally get to satisfy that curiosity, more on that later. The collaboration of these two companies comes from the overlap of interests. GleSYS is working hard to help their customers be cost-efficient in their hardware choices and Ampere's server CPU offerings are incredibly competitive in price-to-performance. And for as long as I've known them, which is more than a decade, this has been a data center provider heavily focused on environmental sustainability. They run on renewable energy, they help heat the cities of Falkenberg and Stockholm with the heat they generate and they build modern efficient data centers. ARM processors are known for their efficiency, and Ampere brings the necessary density for the data center. This is why this is such a neat partnership.

GleSYS also brings the big advantage of being a data center in the EU, removing concerns about the Cloud Act and GDPR. For swedish companies or public sector with special requirements it is even more compelling to store all the data with them. This is now easier as well due to their new managed database service and their established object storage offering. And I've always had great experiences with their customer support, on phone, on email, really top notch.

Now Ampere is a new acquaintance and I'm quite excited because I've seen the announcements of their Ampere One 192-core CPUs and have been very curious. As part of this sponsorship I get to satisfy that curiosity. They'll give me access to one of these awesome machines and since I am who I am I'll put the BEAM on it and see what happens. But of course I have more plans. What's better than one BEAM? Many BEAMs. You'll need to visit Goatmire Elixir to see everything first hand or catch the video later to find out second hand. Or you could read my blog posts on the process.

A massive thanks to GleSYS and Ampere for sponsoring Goatmire Elixir and NervesConf EU.

Secure, obscure and obstinate

I'm working with the Microchip ATECC608, also known in-community as the NervesKey. The NervesKey configuration and usage of the security chip is somewhat straightforward and allows using it for mTLS, securely identifying and connecting the device.

But the device can do more but it has limitations as I've covered in my NervesConf US talk from earlier. Essentially, it can hide secrets but is cleartext when the secrets are being transferred as is part of the public record. The 608 has a bunch of neat features beyond the 508. Suffice to say the chip can be configured in ways where if you can ensure the physical security is sufficient you can get some pretty good protections for things like disk encryption keys. Essentially adding a Root of Trust to a device that can't do it on its own.

The chip is a bit of an asshole. As it should be. It is cheap hardware doing a difficult job with high demand. Frankly. In this market. Who can blame it. But as one of it's co-workers I'd love if our relationship wasn't quite so adversarial.

Essentially I am fighting tooth and nail to confirm pieces of functionality on this device and trying to figure out where and how I am building my message incorrectly to get the damn thing to hash right and perform a CheckMAC or even just a MAC without mismatching. Gotta love reproducing the material for a hash. I've had to do it for some HTTP auth thing used by the fediverse and that was a little finicky but at least everything is plaintext and the expected direction.

Here it is like "oh the mode byte, that's constructed from these bits that we show in reverse on the datasheet, then this thing is a two-byte sequence so we use little-endian for that. Large chunks of key or challenge material. Regular bytes. Probably. Because at this point you know what regular is, presumably." and if you get it one bit wrong it isn't just slightly wrong but completely wrong. Because cryptographically secure hashing.

This reminds me of Frank talking about debugging something in some OpenSSL code and how unpleasant that is. Because every problem is expressed as generically as possible so as to not accidentally disclose useful information to an attacker. This is the hardware variant of that. Progress is happening but I'm learning a lot about my approach.

Oh, did I mention, any time I've found I've misconfigured the chip. It is toast forever. I think I'm on number 13 at this point. But I'm probably pretty close. Or many bytes off.

Thanks for reading. I appreciate it.