Secure boot support?

[dugtf]

Hi,

I think it would be nice to allow stage 1 to check the hash of stage 2 in order to support secure boot. I'm not a macos expert but IIUC currently an evil maid could boot from a usb [0], mount the efi partition, and replace the stage 2 with a malicious binary without entering the admin password. All that renders locking of downstream u-boot and grub moot. It would be nice to be able to simply set the hash of stage 2 via a config variable.

[0] If booting from usb requires a full-security mode, then I suppose one could boot from an official macos installers, install a separate macos, perform the attack, and then clean up the macos afterwards.

[dugtf]

Also is there maybe a list of all of the config variables for stage 1?

[marcan]

This is already planned - that's why we wrote the chainloading support in stage 1 in Rust, to make sure when secure boot comes that it isn't vulnerable to memory corruption issues (particularly in the FAT32 support).

However, I want to offer proper secureboot that integrates with the SEP too, so I'm not in a rush to implement this until we better understand how that all works. In the meantime, the evil maid hole is easy to plug: just enable FileVault in macOS. That will gate all recovery actions behind entering your macOS password (including booting installers from USB; booting OSes from USB ls not really supported at all on these machines and would require your password already to set up the boot policy anyway).

[imlibra]

Is there any information about reverse engineering of SEP? There is already a TRNG API in sep.c .

[dsseng]

(Some notes from IRC that're suitable for this issue)

<marcan> that's a fair point, but a bit tricky... and at that point, it might actually make sense to make m1n1-stage1 able to boot multiple stage2s. That also, conveniently, solves the device tree incompatibility problem, by allowing separate DTs for each kernel.
<DmitrySharshakov[m]> We can use AES + password-derived key I guess. recoveryOS part of the installer generates the keypair, burns pubkey into m1n1-1, and encrypts private one to be stored in the ESP
<marcan> that's a bad idea, it lowers the security guarantees of the platform
<marcan> it's not possible to guarantee secure erasure of such a key file (this is why apple have effaceable storage), and therefore you potentially forever tie the security of secureboot to the user password, even if they change it
<marcan> but if we can do SEP-backed FDE that's much better and solves this problem
<marcan> ideally we figure out some SEP voodoo to allow wrapping the key file with that in macOS in a way that is then accessible again from Linux, but I'm not entirely sure that's possible, though it ought to be, since FileVault works like that?
<DmitrySharshakov[m]> At least that 'first approach' I suggested gives the same degree of security as custom sb keys on PC platforms. Btw you could also store the key on external media or do a secure erasure of the key material when changing the password
<marcan> "secure erasure" isn't a thing on SSDs
<marcan> "secure erasure" isn't a thing on SSDs
<DmitrySharshakov[m]> Well yes. But the risk is still low enough for casual users and attacker will have to desolder NAND to take a look at lost fragments of a broken cryptocontainer (which first has to have a compromised password or cryptography)
<DmitrySharshakov[m]> And for high-value cases a config option can be set to store the key on external media which can be wiped better

I propose a best-effort secure boot policy (embed a key in m1n1 stage 1, pass it via an encrypted file in the ESP, sign bundles of (m1n1 stage 2 + u-boot + kernel + initramfs) with it from Linux (decrypting the key with user's password).

However, this has weak points when the password being used is compromised and data can be retrieved even after deletion. But I think for now we can try implementing a simple secure boot with this flaw. In case this has to be extra reliable user can save the key on an external medium for it to be better removable. Of course, when SEP drivers are ready, those can be used for proper security (wrapping the key).