Author

Topic: Problem with hardware wallets - Much simpler solution? (Read 119 times)

newbie
Activity: 10
Merit: 1
Ok, having read about more potential vulnerabilites, with trezor, (the latest here https://www.ccn.com/trezor-defends-crypto-wallet-security-after-ledgers-mit-bitcoin-bombshell), this has triggered me to share thoughts i've had for a while. This is a combination of explaining my ideas for the solution to this problem, along with exploring the nuts and bolts of exactly how these hardware wallets seem to work. I'm sure there may well be cross over between the two. The crux of what I intend to get at is something similar to a hardware wallet, but that avoids many of what seem to me to be flaws. It does not need to be physically connected to a computer, does not need to update (or rarely), does not or cannot connect to the internet, does not store your private key inside (unless you chose for it to), cannot be used to empty your wallet if it is comprimised, and does not have a private key or recovery seed come with it, (to avoid the risk of it being comprimised). You would enter your own private key or recovery seed, and could enter a different one instead whenever you like. I will explore my thoughts and musings and the process I went through to arrive at this idea. Maybe this is novel, maybe it isn't, it actually seems fairly obvious to me, but you decide.

We constantly hear about vulnerabilities in secure systems which are then "patched" and updated. But everytime I hear this it just makes my eyes roll. If you have created anything that can become vulnerable and therefore need an update you have already failed in what you are doing, because there is already a risk there. It just delays the inevitable until the next security hole is found and then patched and so we go round and round in circles with an insecure idea.

Lets focus on hardware wallets specifically though, and the problem they are designed to solve and how it can be done in a much simpler way with a similar idea perhaps with subtle differences. Firstly, the fact it even needs to connect to the internet at all to "update" is a big weakness. There shouldn't be anything that needs to be updated ideally, and the fact that it is online at all is a security risk because of the potential for hacking. An ideal device would be airgapped and either never need to connect online, or literally not be able to do so. Thats the first point. I think I have heard that the secure areas of the trezor which contain private keys are totally separate from the rest of the operations, or at least the parts of the system which connect online. I am quite dubious on how 'separate' they can really be though. I also know the private keys never leave the device. Ok... that sounds good in principle... but wouldn't it be even better if the private keys were not even on the device at all?!

I will explain how I came up with the more specifics of the idea before I go further and it is pretty simple really. I was using MEW, did not have a hardware wallet, and really didn't want to put my private key in to their website. So I used their offline transaction feature. This is a brilliant and genius concept. However it was extremely cumbersome. I was using an airgapped computer to generate the keys which I then would input in to the online computer. Because of the separation, I ended up just manually typing every letter of the private key and other long pieces of information when transferring between the machines. The next obvious thought was... how the hell can I do this more quickly and easily?...

Wouldn't it be good if I could just scan the QR code or something with the offline computer to transfer the info between the 2 devices if i had the necessary software? Then I imagined how this whole process could be streamlined and simplified even more. What if you could just get a smaller airgapped device to do this much more easily without needing a whole pc? A device with the built in ability, (software and hardware), to scan the QR code and quickly without the need for any of the other crap involved in using an airgapped computer that is not necessary to this task. What I thought you DON'T want however, is a cable which connects the 2 devices together, then the airgapped purity could be put at risk from hacking or malware etc if it found a way to jump across if the other device was compromised somehow. If the communication method is simply through scanning QR codes then only the necessary information can pass between the 2 devices.

Imagine if all this happened in a small device you could hold in your hand?! (not a phone obviously!) - You could avoid the need for any private keys to be stored on the device AT ALL, by simply having it keep a record of several one time offline transaction codes, (however many you felt comfortable with), or just do them 1 at a time. You would only need to scan the private key in to the device when you wanted to renew them and it would not be saved in the device. And even if it was somehow, the device will never be connected online so it would never be hackable anyway, and therefore never need a security patch or any other update so long as the offline transaction system protocol remained the same. There could be contingency to allow one way movement of data in but not out (like through USB slot) if it REALLY had to be updated at some point due to an important protocol change for example, or to add compatibility with more coins if you choose to have that, but that should be rare. Other crypto currencies could easily integrate an "offline transaction system" in to them like with the Ethereum/MEW one if they don't already have one.

I then thought to myself.... Isn't this exactly what a hardware wallet is and how it works then?! - But then I thought no.... Because they still have to be physically connected to the computer, they still have to connect to the internet, and don't have a QR code scanner!

So does anything exist like this? And would it not be a better idea in many ways? If the private key in the likes of a trezor was truly airgapped within the system, and the private key was inaccessible, then why all the vulnerabilities that keep being discovered in need of patching? Oh and also there is the massive risk of course that the company could have some backdoor way in, or some bad employee could have aquired the recovery phrases somehow before the device was bought, or the device simply doesn't really work the way they say it does etc etc etc - The flaws go on and on. If there is only unidirectional data transfer through QR code and usb slot, then that pretty much seems to resolve those potential risks. Of course one could then argue that you now have teh original problem of how to store your keys securely, but that is a slightly different issue not quite within the scope of this. I am happy to explore that issue also though if anyone wants to get in to that as well.
Jump to: