Thread by @XenoKovah

Thread: This would perhaps be a good time to point out that while it’s absolutely true that Windows’ UEFI SecureBoot is intentionally not designed to defend against physical presence, that’s actually an improvement I shot for with Mac SecureBoot, first on T2 and then M1

https://twitter.com/dwizzzleMSFT/status/1425495829511430145

I termed the security goal “P != X” meaning mere physical possession *in and of itself* should not equal code execution. Rather, possession must be combined with knowledge of an administrator password before you could disable that critical security feature.

I was able to shoot for this because Macs have a couple things going for them: 1) the first user which is set up is an administrator user by default 2) all Macs have a “recovery OS” (originally an HFS partition, and then an APFS volume), which has always been digitally signed

(The “everyone has an admin password” is in contrast to PCs which have an option for a BIOS password, which as David has said previously and which I agree with 100%, optional security gets incredibly low adoption rate,here’s my reminder to set a Mac firmware password on pre-M1s!)

The recovery OS gave us a presumably-intact environment from which to perform security-sensitive policy changes. On T2 systems then there was an admin password prompt in front of Startup Security Utility in recoveryOS before you could downgrade the boot security policy

(I would sometimes get complaints from people who’d open a new Mac, and go to recoveryOS immediately and try to turn off SecureBoot, but it wouldn’t work because they didn’t have an admin yet, to which the response was “sorry, gotta make an admin first ¯\_(ツ)_/¯”)

On T2 Macs that’s really just a policy enforcement within recoveryOS running on the x86. For M1 we then sought to improve it to make the locus of control be the SEP with cryptographic entanglement with the user password too

That becomes achievable because the the entire LocalPolicy (LP) (which is what has the security policy settings that are consumed at boot) is signed by the SEP. As soon as the first administrator is set up, the Owner Identity Key (OIK), which is what signs the LP, becomes

protected by the Key Encryption Key (KEK) which is inaccessible without knowledge of the user’s password + the correct firmware and software measurements (key hierarchy shown here: support.apple.com/guide/security… and the protection of the OIK by KEK is here support.apple.com/guide/security…)

So anyway, that’s all just to say that when defending against mere-presence attacks, we then still tried to evolve it to be more hardened against actual exploitation attacks. Because the presumption is that getting code execution on the SEP is harder than in a full recoveryOS

(Because recoveryOS is a stripped down macOS which obviously has a lot more attack surface.)

I suppose I should caveat all this by saying that P != X presumed use of FDE, without which of course someone could simply mount a drive (Target Disk Mode anyone?) and steal all your data and inject Mac autorun malware of course

So, if P != X requires the opt-in of FDE, can PCs ever achieve similar guarantees? It’s less user-friendly, but clearly BitLocker + TPM + preboot PIN gets you pretty far there

But it’s been a while since I’ve looked into what other avenues still exist on PCs so I can’t at this time say how much farther remains to go

Correction on 2nd link: support.apple.com/guide/security…

(To self: “wait, farther, or further?” From google: "farther is for physical distance and further is for figurative distance.". So “further” I guess ;))

Oh right, but I should say that even though the password check is just a policy check in recoveryOS, the T2 actually can tell whether you booted recoveryOS vs. macOS, so even kernel code execution in macOS with a user password wouldn’t be able to ask the T2 for the downgrade