Our roadmap for improving security of verifying updates is based on taking advantage of the reproducible builds. We plan to have multiple official build locations and a configurable signoff verification system in the update clients also usable with third party signoff providers.

We don't have faith in any available commercial HSM products being more secure than keeping keys encrypted at rest on the primary local build machine. Instead, we're planning to develop software for using the secure element on GrapheneOS phones as an HSM for signing our releases.

@Canine3625 YubiKey doesn't even support firmware updates. Instead of having verified boot with cryptographic signature verification and downgrade protection along with update signing and downgrade protection, their firmware cannot be updated. They cannot fix security flaws on their products beyond releasing new ones. Many of their products have been found to be vulnerable to exploits at a firmware or hardware level and they do not even have the option to release patches for those issues.

@Canine3625 We have very little faith in the security of products from Yubico and other HSM vendors. We would consider it to be a downgrade from having the keys stored encrypted at rest on the primary build machine. The primary build machine being exploited would already be a disaster and needs to be protected against. Signing keys aren't actually super special compared to the security of the builds. We don't want to create a weak point for signing keys through an attempt at improving things.

@GrapheneOS @Canine3625 The main use for a hardware token I could think of would be make it impossible for it to be leaked somewhere by accident or in backups.