Secure Boot for HAOS

Feature Requests
1

Please, can we have Secure Boot support on HAOS?

I have resigned myself to HAOS only instead of installing HA Supervised. This is the second deprecation I’ve had to endure - Ubuntu was booted off the supported list and Debian stock used to be mandated. Now that is gone too. I look after several HA instances.

HAOS does not support Secureboot. You “just” have to ensure that you use Shim or similar and sign the kernel and modules. It is a bit complicated but far from rocket science. It is not the be and end all of security mechanisms either but it is available and I suggest that it ought to be used because there is a good chance that hardware will eventually mandate it.

I do get that you will have to get a set of signing keys that chain back to the UEFI built in keys (MS) or persuade someone else to sign kernels and modules on your behalf.

It might be wise to dive in now on this instead of waiting until the only hardware available is a grey market board with SB switched off. Think of it like the coming SSL/TLS certificate lifespan shrinking. You will have to get to grips with ACME and cert. recycling within 45 days or your browser will refuse to show you a website.

I’ve just had to switch off SB on my smart new HA box and I felt a bit annoyed. I could put Proxmox on it and run HA as a VM and perhaps I might but I think that if you are going to enforce the OS choice for your users then you should be fully responsible for that decision and do the whole job and not simply skip the inconvenient bits.

2

Thinking about it: VM it is, for me, in this instance. That won’t wash on a RPi but I have a Core i7 based box with gobs of RAM and SSD.

I’d still like to see SB support because I suspect that in five years or less it will become mandatory.

3

There are three quite major issues with secure boot:

  • the certificates/ signing services cost real money, quite a lot, yearly and for each signature by MS
  • you need to split out the whole critical path (at least shim) from the normal package builds, so they can be (rarely) sent up to MS for signing - and then have to re-integrate the binary results into your image, keep in mind that each signature process takes weeks++
  • it makes ‘just rebuilding from source’ and development much harder, as you suddenly need a signed- and unsigned build process (doubling the chance of bugs)

On top of that, setting up the whole process (packaging, buildd network, certificate chain of trust, who can do what, how to handle remote signing securely, etc. pp.) is quite some effort. I would recommend against this, as it’s an expensive and bottomless pit - and effectively hands MS a killswitch.

4 Likes
4

You are absolutely right … but

There is a fair chance that it might become mandatory or close to mandatory in the not so distant future. If hardware enforces SB then all your arguements are moot.

I mentioned TLS. I’m sure you are aware that TLS certificate lifespans will be enforced down to 47 days: TLS Certificate Lifetimes Will Officially Reduce to 47 Days | DigiCert Already you can get in a bit of a state with your own browser trying to access your own stuff. SB is likely to follow this sort of wankery “for your own good”.

5

I’ve seen similar set of points for several projects now, and they’re kind of frustrating, because I think there is some misconception about SB support: it’s not about supporting “fire-and-forget” installations, it’s about supporting protocol itself, like an optional feature that is still there.

What I think many people mean about SB support (an I am among them) is the ability to trust HAOS developer team, which has nothing to do with MS or signing services.

As you know, SB consists of three major parts (others not relevant here):

  • Platform Key: using it, you trust the manufacturer
  • Key Exchange Key: using it, you trust OS/software developer
  • Image Signing Key (db): using this, you trust the specific software/building pipeline

With that, some background about my common setups (not everything is relevant, just for the whole picture):

TLDR: I manage my own Platform Key and sign KEKs I trust manually

  1. Every system has my own Platform Key. With that, I’ve effectively revoked my trust to the manufacturer and took it in my own hands.

  2. Due to an unfortunate reality where so few teams have their own KEK, the same goes for KEK. Here I’m not revoking my trust, but I’m forced to go through complicated process of self-signing more things than necessary to actually give that trust to the developer. And this is the place where question about OS supporting SB should actually raise itself. In better world, I would just enroll Arch/Ubuntu/Debian/HAOS/etc KEK and recent ISK of such a developer and that’s it.

  3. For the same reasons, I maintain my own ISK for each system. Every system that is intended to be auto-updatable, uses full disk encryption to protect that ISK private key. Again, in better world, this part will be as easy as initial provisioning of KEK/ISK certificates from developer.

  4. Anything that does not allow for persistent rootfs modifications to implement such mechanism or does not support FDE - goes into VM on the system which does.

  5. MS stuff is an exception: I never trust their KEK and add two their ISKs manually.

I know, this is a complicated topic, and I’m quite dedicated to security-at-rest. It’s my passion, and not everyone share this. But it does not mean systems should not bother with this. Actually, the whole situation where everything is bound to MS signing procedure is effectively a consequence of major non-MS players willingly sticking with it. I know, just providing KEK/ISK was not enough for them: MS shit still will be “fire-and-forget” while theirs will require manual intervention, but these approaches are not mutually exclusive.

So, to your bullets:

  • With providing unsigned KEK and ISK signed by this KEK it costs nothing.
    For someone with «since it’s unsigned, it can not be trusted» argument: how do you verify GPG signature of software you download from a site? Maybe you import previously untrusted certificate into your keychain? Or even better, you just compare hash sum of the binary?

  • This part is irrelevant, because shim is not used at all. And while we talking about it: here is another approach to somewhat support SB - MOK keys (curse of a secure boot, but still).

  • This becomes irrelevant either: you always sign your builds. For development, for systems without SB, for any current case where SB is disabled for HAOS to be runnable or for user not bothering with SB - nothing changes, signed system still boots as it did before. But on systems with SB and willing user - chain of trust can be easily maintained.

The only questionable part is a signing itself, but I can not suggest anything not seeing processes from inside.

My point is: SB does not enforce manufacturer-MS bundle as a root of trust. Having your own KEK and ISK signed by this KEK does not imply MS/signing services burden at all. Point of SB is to trust OS/software developer, and not trust Microsoft with right to trust something on my behalf. So, supporting SB means providing the ability to trust your software directly.

For that, developer should provide it’s KEK certificate for people to be able to enroll if they decide to do so, and signing it’s UKI with their ISK. That way developers can rotate ISK keys whenever they want without relying on the MS shit, and people can trust HAOS by simply signing and enrolling HAOS KEK. Or not bother and boot as they used to, without SB.

6

I’m fully aware about that possibility (and I’m not speaking for the haos developers, I’m just a beginner with haos, but very familiar with general purpose distributions and their development). MOK and friends is of course a possibility, but a very painful one - I wouldn’t (don’t) expect any normal users to get that working. Right now, switching secure boot off is considerably easier than the alternative (for which details will differ greatly between mainboards, so documentation would be ‘fun’).

Secure boot is quite harmful if you want to do development/ build your own kernel, grub2, etc.

4 Likes
7

I would like to know this source. Because I have no indicator this is true.

Now what would SB be used for?

Secure Boot is protecting the os from malware at the firmware level by ensuring all code that runs at ring 0 is signed. Great! Love this. (yes problems, lockout etc but let’s run with this)

Ok we are protecting what exactly.

No. Seriously

You need secure boot on w11 plus to be able to verify the trust chain all the way down to disk encryption etc. It’s the whole reason ms will NOT come off that hardware req. For W11 (if you think otherwise you are very wrong there are us defense and government gigs that rely on that stuff w10 retires in Oct)

Are we doing encrypted disk in haos? Nope
Are we verifying a trust chain? Nope SSL barely login eh once you’re on the box you OWN it seriously (this is the same reason should NEVER expose your login endpoint to the open internet without an SSL terminated reverse proxy or something like Nabu - poke poke poke - bufferoverflow - pownd, allyourbasebelongtous

Everything that is not an addon is in process with HA core there is no such thing as a secret inside the os. (with obvious caveats)

So before we ask for secure boot (again I like secure boot) we need tk to talk about the many many many other things in haos that need serious attention. Starting with a real role based access controls and zero trust design there because honestly until that happens you’re just building infra for infra sake.

Now let’s assume they do shore up the sec model. And they get true role based security and full volume disk encryption from boot. Then sure get secure boot.

Me I’d rather have the folks who know security stuff prioritizing the HA core and working back out from a rebuilt access model imho.

4 Likes
8

Nathan

Secure Boot is a thing and there is a good chance that it might be made compulsory across all platforms by people with way more resources than you or I.

I’m not actually advocating Secure Boot. One of my jobs as a … nerd … is to identify risks and opportunities.

SB is an opportunity:

If you sign all the layers from BIOS start to a demonstrable point, you can have some confidence that the code involved is what you want it to be. As with all things IT, there are bugs but we know how to deal with those and I think it would be shit to disregard a useful security effort.

It’s got bugger all to do with Win11, it is useful for Debian and Ubuntu and all the rest who already sign their kernels and modules. I do get that there is a barrier to adoption here which is naff but not insurmountable.

SB is a risk:

SB is controlled by third parties, who may not have even heard of Home Assistant - mostly Microsoft. MS has rather a lot of clout with hardware manufacturers. Already anything that wants to run Win11 will need to support SB. OK if SB is able to be switched off then HA will be fine. If it isn’t then not fine.

There is a risk. We at my company classify risks with two parameters and we pop then on the risk register. I’m sure you should do the same.

If you don’t, I suggest you do rather than slagging me off.:

“Me I’d rather have the folks who know security stuff prioritizing the HA core and working back out from a rebuilt access model imho.”

I do quite a lot of IT security stuff myself - what with running a small IT company for 25 years. I can also drive a carriage and horses through a slack jawed argument.

Cheers
Jon

9

I agree it’s a risk - but temper said risk against a tiny mostly volunteer staff AND a buglist longer than either of our arms AND the fact we could both drive a truck through the auth model… Go look it needs work.