Add message signing

[ghost]

A better long-term solution for putting out official builds of Krux would be to sign the builds (or rather, the sha256 hash of the builds) with Krux itself. Since it's already an airgapped signer, it's a little odd that the current build process has you enter in a private key at your terminal to sign the build with when you have a device capable of doing the same thing more securely.

Therefore, I'm changing the Sign PSBT option into Sign, and if you select it you will be taken to a new screen with two options:

- PSBT -
  Message

If you select Message, the camera looks for a QR code to scan containing either a sha256 hash or an arbitrary message that will be hashed using sha256. It will then prompt you with the hash and ask if you want to sign. The hash will be signed with your extended master private key, and you will see a base64-encoded version of the hash in text form, and a QR code will also be displayed containing the base64-encoded hash.

[ghost]

Originally, I further stated:

As part of this, the firmware update process will be updated to scan a QR code of an xpub that can be used to verify the build's signature, which means the code no longer needs to store a signer pubkey. A nice benefit of this is that if my private key were to become compromised, I could generate a new keypair and sign a new build that existing Kruxes could use to update.

Upon further thought, I think that this would make it too easy for someone to install arbitrary firmware on the device with only an SD card and QR code (of an xpub). For now, I'm going to leave the firmware update process as-is with a pubkey baked into the build.

In the future, though, it may be useful to have the aforementioned update method for the reasons given above. A workaround to prevent a rogue update in that case would be to store some kind of hashed password on the device (a login, basically) that the user must enter to perform a firmware update.

Regardless, it's always been possible for a rogue actor to re-flash the device with custom firmware just by plugging it into a computer over serial. That firmware could theoretically look and behave just like Krux, but do something nefarious like write keys to SD or wait to be plugged into a computer to contact a server, etc. I'm not sure how to solve this problem... or if it even is solvable with the M5StickV? For example, Trezor solves this problem by storing their "boardloader" in a write-protected area, preventing any future updates to it. In our case, Krux is the "aftermarket" firmware for the device, so whatever we can do someone else could, too.