I looked at the site overall. I can't really comment on the hardware tooling since I don't know much about that topic, but the amount of detail that's included plus the effort to not over-promise make...
Thanks for taking the time to look over the site.
Yes, that's exactly the residual trust. We can make the firmware verifiable, we can't make the silicon verifiable from your chair. We'd rather say that plainly than pretend otherwise.
On signing, the firmware signs three things with three separate keys:
1. Bitcoin keys sign PSBTs only. Always behind a separate spend PIN with physical confirmation on the device. Transport is your call, fully airgapped over QR or over the local network.
2. Your Nostr key signs events, any kind, either locally to the web app or remotely via NIP-46. Plus NIP-44 encrypt/decrypt for DMs. The key never leaves the device either way, only signatures come out.
3. A per device attestation key inside the secure element signs genuineness challenges and CIPHER game scores. Device identity only, never touches your keys.
No generic "sign this hash" API anywhere. And since the hardware itself could sign anything, that scope is really a property of the firmware, which is why it being open and reproducible matters.
That said, developers may well want to sign with other kinds of key pairs, and for that we may offer unlocked dev devices. Their attestation keys would live on a separate dev list in the registry, so a dev unit always verifies as a dev unit and can never pass itself off as a production device.
Yes, that's exactly the residual trust. We can make the firmware verifiable, we can't make the silicon verifiable from your chair. We'd rather say that plainly than pretend otherwise.
On signing, the firmware signs three things with three separate keys:
1. Bitcoin keys sign PSBTs only. Always behind a separate spend PIN with physical confirmation on the device. Transport is your call, fully airgapped over QR or over the local network.
2. Your Nostr key signs events, any kind, either locally to the web app or remotely via NIP-46. Plus NIP-44 encrypt/decrypt for DMs. The key never leaves the device either way, only signatures come out.
3. A per device attestation key inside the secure element signs genuineness challenges and CIPHER game scores. Device identity only, never touches your keys.
No generic "sign this hash" API anywhere. And since the hardware itself could sign anything, that scope is really a property of the firmware, which is why it being open and reproducible matters.
That said, developers may well want to sign with other kinds of key pairs, and for that we may offer unlocked dev devices. Their attestation keys would live on a separate dev list in the registry, so a dev unit always verifies as a dev unit and can never pass itself off as a production device.
1