That's cool! Good work!
So you use the device to generate a private key and encrypt it with a password. You write the passworded key down (paper wallet) and store it safely as a backup in case you lose the device.
When you want to transact, you generate a signing request QR on your computer. The device scans it in and asks you for your password. It then generates a signature QR which you scan using your computer. Your computer adds it to the transaction and broadcasts it.
Er, wait, the device wipes its memory every time you use it, so you need to type in your passworded key and password every time. Sounds like a PITA that leads you to leaving your paper wallet lying around (printing a passworded key QR is nice but beyond the paranoia level of this device).
The device will have to have the unencrypted private key in memory at some point. How about the device stores the passworded key in volatile memory which gets wiped after a window of time, loses power, or you get the password wrong? It could possibly also be in a TPM of some sort that does the signing, inaccessible to the OS or memory to make it harder to dump from memory if the device is stolen within that window of time.
Note that normal RAM isn't truly volatile (
https://citp.princeton.edu/our-work/memory/). You can freeze the device, kill its power, and then boot it from a memory card with a tiny live OS that dumps the raw memory that's still frozen in time from when it lost power.
The obvious attack is to steal the device, install a keylogger, and then put it back where you found it.
Maybe having read-only firmware and no USB or memory card ports would help for the above scenarios.
Thanks! So no sensitive information is ever stored on the device, which is proved that after boot you can eject the SD card before you use the vault app. SD card has a custom linux OS which completely runs off a RAM based filesystem with no swap + vault app.
Every time you have to import your mnemonic phrase + passphrase before you can manage your existing wallet. To make this a little easy, you can choose to generate an encrypted QR code (AES encryption) for your mnemonic phrase, which you can scan during import to not have to type in those 24 words. You can easily store this anywhere digitally since its AES encrypted and even if that's broken, you still have passphrase providing you 2FA. This goes along with the "extremely cautious" or "paranoia" approach I am aiming for.
Sensitive bit is indeed stored in memory after you import it and before you turn it off. Even if its encrypted, the encryption key is going to be in memory too, at some point. But what are we protecting it from at this point? Even if there is malicious programs running, where are they going to save info for any attempt of later retrieval? Is saving info on firmware and later reading from it, a possible threat? I am not very familiar with how firmware functions on Raspberry Pi. How would this supposedly work?
Now coming to physical access attacks:
1) What if someone installs a keylogger? hardware ones are easily noticeable. software ones again pose the question where do they store the info they steal? I will have an on-screen keyboard anyway. Firmware concern remains.
2) Cold boot attacks are really just proof of concept attacks. Someone in the same position, will more likely do a $5 wrench attack than anything else, for which usage of passphrase already allows plausible deniability or unlocking a "distraction" wallet with little funds when a specific non-primary passphrase is used.
3) Someone steals the device while you were using it. I have no protection against this sort of attack as of now, but I can add a reset timeout after 60s of inactivity or another auth layer before transaction is signed, though I am stepping outside of the specification here. I don't want the user to remember another thing "PIN" to sign transactions, not to bring up the fact how is PIN chosen because of the stateless nature of the device. Re-entering the passphrase can be an option but it might be inconvenient to input a long one again or perhaps only when the device has seen 60s of inactivity. What do you think about this?
Now, the goal of this project is for people to buy their raspberry pi & parts to setup their own DIY hardware wallet which is trustless by nature, effectively eliminating supply chain attacks as well. So, I can't have a lot of hardware mods in there. But I really want as much criticism as I could get to really evaluate its architecture.
