I recently purchased a Trezor Safe 5, and would like to sign and flash the firmware myself, so as not to trust the firmware that it shipped with. Unfortunately there are a few issues I cannot find documentation for:
no instructions to unlock Trezor Safe 5 bootloader
no instructions to re-lock any bootloader (not just Trezor Safe 5) with self signed certificate
no instructions to tell Trezor Suite to expect my own self-signed firmware, instead of an official certificate from Trezor.
I am an advanced user (fw dev by trade), and comfortable with compiling & flashing firmware as well as compiling the desktop/android apps.
I think “not trusting factory firmware” is a common desire in this space, and I am happy to help standardize this workflow and open PRs to the appropriate tools, if Trezor team thinks it would be a valuable addition for users like me. e.g. maybe I can add an option in Suite to specify a self-signed certificate. Or improve the docs to explain bootloader re-locking…
verify that your local build, from your local audited sources, comes bit-for-bit identical to the official one, except for the signature (which will be missing in your build)
then install the official signed firmware, confident in the knowledge that it’s the same thing you would have built locally
This is not a supported feature. Once unlocked, the bootloader cannot be re-locked.
This is in part a technical limitation and in part a conceptual one.
For the conceptual part: once you install unsigned firmware on any of the Safe models, that permanently taints the device. There are now too many features on the STM32 MCUs and the Optiga SE, not all of which can be 100% audited and 100% reset to initial configurations. So even if you reinstall official signed firmware, the device must no longer register as authentic Trezor.
But if you want to “re-lock” with your own certificate, so the device wouldn’t register as authentic anyway, resolving the above conceptual problem.
Unfortunately, the Secure Element configuration is locked at manufacturing time and cannot be unlocked. Simply put, the SE chip itself doesn’t have enough capabilities to support relocking – although, in theory, we could keep one private key slot and one certificate slot free and unlocked, so that users can implement their own authenticity checks.
But even if we do, you probably wouldn’t want to stop there: then there’s the internal firmware integrity chain, where you would have to figure out a way to (a) store your own public key somewhere, and there’s not a lot of places left to do that, (b) somehow special-case that stored public key to consider it “locally trusted”, while at the same time (c) make sure this does not enable any supply-chain attacks (so specifically the red “UNSAFE DO NOT USE” screen must stay somehow).
given the above, Suite doesn’t have this feature. You can of course disable any of the authenticity checks in settings.