Topic: Would you be willing to flip coin / roll dice 256 times for security of funds? (Read 341 times)

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.

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.

No.

I love flipping coins anyway and it's one of my talents, this could be interesting 

The total time for coin flipping was 16 minutes (approx. 3-4 seconds per each flip).

https://www.youtube.com/watch?v=WyBdYhwweaE

Allow me to explain the architecture of the entire system & I would love for you to criticize that. Assume my intentions to be malicious for the purpose of criticism without worrying about offending me. You can forget about this question altogether, as I realized instead of aiding the user to generate mnemonic phrase in "bring your own entropy" method, its much better to do that process completely offline. So that's what I recommend now and I will provide community vetted instructions for the same.

Here is how it looks: https://imgur.com/a/JYQjrVG

Ok, so for the architecture, I am using a Raspberry Pi with a custom linux OS and the device never touches any network whatsoever, this acts as your cold storage solution. It stays offline for its entire life. Even all the Proof-Of-Concepts air-gapped attacks I came across in my research are rendered useless here as it has no speakers, no fans hence it has no medium via which malicious software can even attempt to leak out the sensitive information. The sensitive information is not stored on the device at all. You have the option of ejecting the bootable media (SD card) before you choose to use the vault app (software), so that it has no storage media to write to.

The vault app is quite simple - It has generate / import option when it starts since it never stores anything. Also make physical theft of the device useless. You always import your mnemonic any time you want to use your vault and it generates xpub keys and shows QR code which you import on the wallet software which is either a hosted service or you run it locally. You use this wallet app for all purposes of monitoring your funds, generating addresses for receiving funds & start the process of signing a transaction. All communication happens via QR codes, which can be read by a third party software at any time to see what data is being transmitted.

For convenience, you can generate an encrypted version of mnemonic and use that to import your sensitive information in the system by simply scanning that QR code, instead of having to type your mnemonic (24 words).

Now two kinds of attack that are possible on a system are:
1) Generate false crypto information (xpub keys), which can be verified from the source code
2) Stealing crypto sensitive information (mnemonic phrase or private key) which by architecture and communication medium severely limits the attack vector. Much more secure than relying on a USB/Bluetooth communication layer.

Its a free, open source DIY (self assembled) crypto vault that gives you great security at a very affordable price of ~$65 Since you put it together, there is no scope of supply chain attacks either.
That's what my goal of the project is - Enabling individuals to defend their sovereignty. Happy to discuss this further & looking forward to your criticism

The question is moot because the Linux OS and firmware running on the Raspberry Pi can just keylog your private key anyway, or transparently use its own when it comes time to actually generating your public key, or choose its own nonce values when signing, or any number of things. You either trust it or you don't. And when you're known to trust it then you can become a target of whoever makes it. That's why Trezor makes their own hardware. https://wiki.trezor.io/Security

How do you input/output transactions with this device? How do you back up your keys?

I hate to be a downer though, so here's some comic relief https://dilbert.com/strip/2001-10-25

Thank you! I realized I kinda opened a can of worms here without proper documentation 😅

I am very close to getting the MVP built out. Something before the end of this month. Most likely early. I will eventually present this to the community with motivation, documentation & security offered against several attacks, purely by architectural decisions.

Well, it was just an idea I was discussing. You probably didn't read the entire thread but I was basically trying to offer a "bring your own entropy" option at mnemonic phrase generation step, but since then I have decided that its best to do that completely offline if you are extra cautious since its a one time thing.

I am trying to reach as trustless of a system as I can build. Its not about whether I trust my RNG or not, being a software dev, I can verify it. Its about enabling individuals to have sovereign money without them getting rekkt on the security side of things.

You have a valid point about random number generation while signing a transaction, and that point isn't that a lot less severe? Once UTXO is spent, what's there to lose? Losing your mnemonic on the other hand is a big deal, but using passphrase protects against that as well.

Please poke more holes at it, if you disagree at some point or anything else. Need as many eye balls on the architecture and eventually source-code ✌

Although there are who react negatively about your idea, it is still encouraged and commended for bringing this up to the community so you will have additional input or consideration on how you going to present your product to suit the community, this is a project development project with anything related to this technology I hope you can come out a finished product that can be of use by the community, we need to keep this technology to move on because it's dynamic.

Why would I flip a coin 256 times if I can roll a 16-sided die 64 times instead? Or at least I can roll a 8 sided one 128 times. But frankly, if you don't trust your RNG, you should probably not use Bitcoin and all other things, like even browsing the Internet, because a backdoored RNG opens countless possibilities for the atackers. For example, random numbers are used in the ecdsa signing process, and if they are not random, then it's possible to retrieve a private key. So, good luck flipping a coin 256 times every time you're making a transaction.

Well, as long as you use a Raspberry Pi Zero (non-W) or desolder the wifi and bluetooth module from the board if you are using any model that has wireless network options, you don't need to care about the OS at all.
I have specifically chosen this architecture based on different air-gap POC attacks as well.
The only bit you would need to verify in the application (as long as you generate mnemonic completely offline or already have one) would be just the QR codes that are passed between Wallet & Vault. Which can easily be done by a simple QR code reader


I realize that. I couldn't buy a hardware wallet because of the lockdown, so I decided to build one myself and based on my months of research, I kept on refining the architecture. I am going to do it for myself anyway and support for decentralized exchanges & dapps support is on the roadmap as well. Contributions though welcome are not required. Peer reviews and some sort of audit is what I think would do some good. I am fully committed to see it through & maintain it in the long term.

P.S. - I actually have been coding the wallet and vault, completely on live stream. YouTube and Twitch links are on my homepage - ashfame.com

this part sounds very interesting to me but also the OS part makes it hard to verify it and i think such project is going to be a huge one. it would also be outside of the range of my knowledge.

i have found that only certain types of projects attract bitcoiners, for good or bad. for example anything that remotely relates to trading and making profit will get a lot of attention.
security related stuff don't seem to get that many contributions though. specially the new ones.

I understand. And I encourage everyone to be paranoid, it would be foolish to not verify and just trust anything when it comes to cryptocurrency. Majority of the users are just going to follow the recommendations of enthusiasts / authority figures anyway, but we as enthusiasts have that responsibility to look after the community.

This project arised out of my own needs, hence I am building my own hardware wallet running a custom linux OS that can truly maintain the air-gap with the ability to verify everything from source code to the end product in hand.

Please see this diagram - https://pbs.twimg.com/media/Ec40sGxUMAA8ycM?format=png&name=large and I recommend you to read the above reply I posted as well. This is the first time I am presenting the project to the community in a lose manner, where obviously the entire vision isn't put out well enough for easy comprehension. So, I will also get to refine the vision and story, the more I talk about it.

And lastly, I hope the community encourages the open source spirit of wanting to verify everything and hacking away to deploy their principles or give voice to their opinions. Criticise it to its last bit, but do participate

Great point! I have not actually considered the act of someone doubting the generation of addresses themselves. A malicious program can print out pre-programmed xpub keys and addresses from a known list.

So, its not trustless for you because you would need to verify it yourself to build trust but you don't wish to. I understand your perspective. But if you wish to, you can and there is no step in the process that you have to just blindly trust to act in good faith.

Trustless as per me is a system where you don't have to trust the system at any point to act in good faith. Its verifiable at every point from the source code to final product in hand. And that's what I am aiming for, in the project. Scratching my own itch & learning

Right now, what I see, is one has to trust some software or the other. Its painfully slow to do it all manually that software can't be practically eliminated from the usage. So one must verify the software themselves to act in good faith or rely on others to have done the same for them.

Same reason why its recommended to build from source rather than using pre-build binaries.

Now, once you have laid down your trust in an application to use, the second concern is of the environment in which this application runs. Can you trust the environment (verifying the environment is a huge task & controlling the environment is a tough task)? How about undiscovered or undisclosed vulnerabilities which will enable the malware to take control of the system and steal funds? A better alternative is to run this application on an air-gapped device, but then several Proof of concepts of different attacks for AirGap devices exist and hence emerges the WHY of my project.

Its not just a software app. Its 2 applications where one runs on a Raspberry Pi Zero with a custom linux OS to act as an air-gapped device where its not possible to get any information out because it truly runs as an air-gap device with no networking hardware available. Another application is just the wallet, which doesn't even have access to any sensitive information, just xpub keys, so you don't need to verify this at all. Please see this diagram - https://pbs.twimg.com/media/Ec40sGxUMAA8ycM?format=png&name=large

So, in a way, this lets you build your own hardware wallet with the ability to verify everything, hence a trustless system, perhaps the only one.

there is a difference between being cautious and paranoid.
so far there has been millions of bitcoin keys created and trillions of dollars worth of bitcoin have been transferred around and to this day there has not been a single case of bad RNG coming from the good wallets like bitcoin core or electrum. the cases were from new, shady or weak codes or services such as blockchain.info, javascript base websites and wallets,...
that is why people aren't really looking for alternatives, specially when that alternative could take an hour of their time and still not be safe.

I don't agree that this makes the system trustless.

Flipping the coin 256 times is not enough to generate a public address, you still need a computer and a software to do that. This would make you need to trust that software, even if it is open source (cause I am not really going to verify the software myself).

Its actually not that straight forward of an attack. It can be in a closed-source but even in open source it can be hiding in plain sight. Its more like the random number generator is limited to a range of numbers either by accident (bug) or design (malicious intent) and then that range can be brute-forced comparatively easily to check for balance and steal funds from.

Also, when you buy a device, you have to "trust" it, which is why my approach is "build your own". Everything is open-source and you can review or trust others have reviewed and use the source to put together your hardware wallet (trustless), rather than relying on pre-compiled binaries (having to trust) or open yourself to supply chain attack when ordering one. You simply order Raspberry Pi, some parts, write files to SD card and done! Trustless system!

None taken, that's obviously the concern I am trying to address here. Its ideal to generate keys completely offline without a computer provided you can use verified secure entropy (as humans are bad source of entropy) and have the know-how. And then rely on an air-gapped hardware wallet to manage everything else

Now, would you go "all-manual" route to generate your keys or you would use a computer at some point in the key generation process? I am trying to offer whatever little computer tool you use in the form of an option, to mix that manual source of entropy into key generation.

Hey there,

No offence, but I'd rather flip a coin 256 times than trust an unverified tool with that. No coder myself, unfortunately, so I can't check whether the tool is not providing me with one of the, say, 10 million keys which are stored in its memory.

Spending extra 25-45 mins is not that much compared to the possible risk of having a private key known to someone else, imho.