Topic: Handle a Wasp and you will not get stung! Practice Safe Bitcoin (Read 6226 times)

I'm running the latest version of your Bitcoin Address Utility from github, and am unable to find the m-of-n functionality.  Please could you let me know whether you've pushed this feature to master on github, and, if so, give me a hint on how to do it.

I'm currently trying to get sorted with a 2-of-3 scheme for my long term holdings.

Thanks.

Three guesses who gets hacked next.

I tried to install QtQr on Ubuntu 12.04 yesterday, but with no success. I'm using "zbar-tools" now and it works great

By never possessing them - at least not any high value ones.  I do think of the possibility that someone could kick down my door and shout "give me the god damn paper wallets", and they definitely wouldn't get much.

I wrote a feature in my Casascius Bitcoin Address utility that allows m-of-n private keys, similar in concept to the one Vitalik Buterin wrote.  It's probably not the version that is ever going to make it as a standard, but it functions for my purposes.  Using it, I can implement safeguards against robbery as well as death/incapacitation.  One of the controls I use is a mandatory visit to multiple places, one of which is a safety deposit box whenever I need to access large amounts of coins, for example, if somebody goes on my website and orders a gold coin etc., and I need to access their payment.  If someone orders a gold coin or anything above a certain threshold, I don't sweat it, because they get a payment address from a different batch of addresses that are kept this way.  I already have to do a scheme like this anyway just so I don't ever possess gold coins any longer than I have to, so doing this with paper wallets isn't that much more difficult.

Visiting the safety deposit box is relatively painless, I just go in there knowing what address I want the private key for, and scan one QR code with my phone, and the paper wallet booklet never leaves their vault.  Once scanned this enables me to do the transaction, elsewhere of course.  Since it's m-of-n, I don't have to worry about the bank personnel having their own key and getting in there and being able to redeem the paper wallet out from under me, nor do I worry about whether the QR app's developer will be able to benefit from the code.

This is the right way to handle somebody else's money, or at least much closer to it than having a giant hotwallet!  Mark at MtGox has alluded they do something similar.

This thread deserves a sticky somewhere on this forum or another subforum.

I didn't say "someone sneaking over your shoulder", I meant protecting those pieces of paper against home invasion type hit on the head / runaway.

I'm reasonably sure the number of persons who manage to remember a QR code is quite limited.

Paper wallets, hear hear!

Maybe put the addresses on 1 dollar bills so that the day your house is robbed the thieves will buy bubblegum whilst unknowingly paying a thousand dollars or so... you know for the lulz.


In all seriousness do you have a dedicated offline computer and printer to print the paper wallets? I hear printers are surprisingly hackable.. though of course the risk of such attacks are quite a bit smaller than unencrypted wallets on online PCs.

(Wasp looks cool)

I'm not sure how that compare to a dedicated netbook with encrypted volume. Netbooks are ~200$, have a camera, and can optionally be connected to the network through a very limited connection.

If someone pop up behind your back, how are you going to protect those paper wallets ?

Securing the PC by hitting a button, or attaching you foot to the power cord could provide a fast exit from intruders.

This thing look no different than typing codes manually or having a webcam/software read it. (both relatively cheaper / free)

Hi Mike,

I used the imporprivkey command a bit with some vanitygen addresses (that were new so obviously had no existing balance) recently and the automatic rescan that bitcoind does was a real pain for me as it takes around 15 minutes on my laptop (so it ended up taking me an hour to import four addresses).

If you (or anyone else reading this that is able to build Bitcoin) has any time to test this patch then provided there is no issue with it I will make a pull request for this option (sorry I don't have time to test it myself as I use VC++ on my laptop, a very old Linux OS on my server and am flat out coding on my own project).

https://github.com/ciyam/bitcoin/tree/importprivkey_rescan_opt


Cheers,

Ian.

+1 No solution is too far fetch when it come to securing bitcoins.

If you're handling thousands or tens of thousands of somebody else's bitcoins, an amount you can't afford to lose, you're already negligent if you're doing so on your mobile phone in the first place.  This advice isn't for everybody to spend $319 to manage their $100 worth of bitcoins, this is for people running exchanges and web shops and those entrusted with significant sums of money, like the 30K BTC that got hacked out of an exchange recently.

So... my phone can do this with the free QR code app, Mt. Gox app, etc.  This seems like a waste of $319 to me, but to each their own!  Why is this better than using your phone?

I assume you mean the risk is that the serial ports have a getty or equivalent process on them, since of course telnet/ssh sessions imply there's TCP/IP which isn't present on a serial port by default.

Wouldn't this be geared more toward the expert user / web developer rather than the general user?  The kind of person who's going to interface with this would be in a position to notice their serial port spitting out "myblackbox login:" ... "Login incorrect" and do something about it that is not likely to be reversed by accident.  Presumably the system process would be swallowing some or all of their communications as though they were login or password attempts, and it should be quickly obvious that something is wrong.

And even if there was a wide open getty process, trying to crack even a medium-strength password against one over a serial connection is an extremely arduous process comparable to watching weeds grow (sort of like watching paint dry, but much slower)...

If this is the only reason you're considering an audio link, are you really sure it's worth the hassle?  You're talking re-implementing codecs from scratch, dealing with differences in audio hardware, sampling rates, ground loops, a potentially CPU-intensive Fourier transformation to decode wave data... for all that hassle, you could just as soon write a scout that scans the running processes, detects errant getty processes and throws a fit once found.

Admittedly, there aren't many brands that have a write-protect switch: we use them at work all the time (a requirement on some systems).  So it's possible, but I don't know how much it would improve security...


Admittedly, I considered this idea seriously before determining that there was increased risk for many users, instead of decreased.  The ubiquity of drivers and subsystems that automatically run on serial ports on many systems is scary.  I was surprised to find out that some flavors of linux will allow telnet/ssh sessions by default over serial, even an IR link!  Obviously, things can be done to avoid this, but I don't know if it's the best idea to recommend to the general user that may not take the appropriate precautions to prevent it.

My ultimate goal will be to team up with someone and make a dedicated device that only receives transactions, shows confirmation on a little screen and waits for a button press, and spits out signatures.  No way to pull the keys out of it.  It would basically be a handheld TPM.  However, I'm a long way off from that.  Until then, I might look into the audio-coupling idea jim618 proposed. 

In the meantime, this device may provide those with a lot of money to spend on protecting their coins, some improvement.  I just have to have Armory display a QR code containing the necessary signatures once it is signed.

I am not sure write-protected USB keys are very common.  I have never seen one.  I've seen write-protect slide switches on SD cards but they are isolated from the onboard components and seem to work "on the honor system", enforced only by the reader if it's able to read it.

But if you (or anyone else) looking for a nifty and unique feature idea for Armory, you ought to consider making Armory offer a wallet interface service that talks to a serial port or a class of things like it (which could include named pipes, telnet/ssh/sockets, character devices).  The computer running Armory would be the "trusted" computer, and whatever is on the other end could ask Armory to sign transactions, at which point Armory would get the user's permission through the UI before doing so, perhaps letting transactions meeting specific criteria (in terms of amount per unit time, or to known/trusted addresses) go through automatically.

This might be an expensive but effective way to execute offline transactions with Armory, but you would need two of them.  Since you need to send the offline computer the transaction, and then send the signature back.  (but it's not really different than the manual ways that people attempt to synchronize the blockchain with the offline computer...)   

The only problem is that there will be the few transactions that will require dozens of bar codes... could be annoying.

Perhaps the best thing to do is get a USB key with a write-protect switch.  Use that to transfer offline-transactions to the offline computer, and then use this device to send the signatures back to the online computer.  The signatures are almost guaranteed to fit in a single bar-code, though the original transaction will not.  This would remove a large portion of the attack surface, since most attacks on Armory cold storage would be through USB drivers of some sort.  A virus can't write your private keys to the USB if it's write-protected...

Hey casascius, did you write any guides on the paper wallet methods you follow?

I still need to test this out as my cold storage is effectively usb keys with their own wallets.

Great! I hadn't actually tried it yet, but I'm glad to hear that it does work. Thanks for the input.

casascius:  how do you secure your printer?