What’s the write protect story on the v56? (Clevo v560TU, I think?)
Also, any thoughts on bios encryption as a future security direction? Ie. A vendor creates a microbootloader with a single instruction - query a security key to decode the encrypted bios blob stored in spi. They sign and publish only this bios, and delete their private key, forever. Their public key is published and can be used for fusing.
Unlike fusing a manufacturer public key, which can be defeated by stealing the private key, control flow is irrevocably delegated to having the security key that can decode the encrypted bios on disk. Mismatches just don’t load usable instructions, but the laptop owner can reflash with a new key/bios pair at any time, but they know when they are doing so by the presence of a new security key. A laptop can go through customs but unless the security key is also present at the same time there’s no way to flash the bios such that the users key would decrypt a useful bios. Similar for remote attacks, malicious updates would be useless unless the signing key was plugged in and toggled by the user.
Seems O(n) secure than the plaintext measure/verify paradigm since the data (measurement, signature) needed to fake is per-user, not per manufacturer (although the user could decide which binaries to sign based on their trusted manufacturers)? One attack surface then shifts to faking a manufacturer update, but its easier for a user to verify consensus on firmware authenticity on the user’s timing (via multiple uplinks, blockchain publication, etc.) vs. the much harder question of verifying whether a manufacturer private key was ever leaked. So a harder problem for the attacker and easier problem for the user.