Client safety against theft of bitcoins

[Hans0]

Currently, the wallet is stored inside the wallet.dat file. There are three potential problems for an ordinary end-user:

1) The wallet gets lost and all bitcoins are lost too
2) A virus gets on the machine and immediately sends away all the money to an anonymous address
3) A virus gets access to a backup of the wallet.dat and proceeds as in (2)

I think the latter two are commonly disregarded. There _will_ be viruses doing a routine check for bitcoin wallets and sending them away in an instant. We must also assume that sometimes a users machine will be compromised. I propose new features in the client to address (2):

It should be possible for a user to encrypt the private keys (or the whole wallet.dat) with a password. The following properties should hold:

- The keys do not exist in memory or on disk for longer than necessary. After use they are wiped.
- Consequently, before every action that requires the keys, the password must be given
- While entering the password, bitcoin.exe switches to a secure desktop like Vista UAC does. This is not a security boundary (meaning it can be circumvented by a virus) but it provides defense in depth - it makes it harder to steal the keys. A screen keyboard should be given so standard keyloggers do not succeed.

Problem (3) is still adressed by the password beeing required to decrypt the keys.

Some of these measures might seem overkill but after all we are dealing with a sizable financial value here. The bitcoin client is like the online banking interface that we all use every day. The difference is sending the money away is untracable, instant and does not require PIN or TAN.

Feedback welcome!

[publickeyhash]

Currently theres on the order of 10^8 $ worth of bitcoins circulating, and the value may keep increasing indefinitely (as society progresses and generates physical value, while the number of bitcoins asymptotically near the constant value of 21 million bitcoins...).

Since backups prevent data loss not data theft (and actually may promote data theft, as multiple copies are lingering on multiple computers/email accounts/....) and since encryption will need decryption when actually spending coins (at some point the private keys reside unencrypted in ram)

So running arbitrary code on a computer will probably eventually lead to wallet thefts. However as the value increases, the value of formal verification and overflow prevention will rise.

I believe Bitcoin will be more effective in eradicating viruses, and raising higher standards on widely accepted programming/scripting languages and file formats like Flash, since any avenue (not just potential flaws in Bitcoin) of injecting malicious code can be used to access the computer. Bitcoin will be more effective than all AV companies combined, it will force us to solve vulnerabilities at the design point, instead of having AV mobs racketeering individuals for their protection.

(compare the revenues received from malware/AV ads with the future value of cryptocurrencies)

cryptocurrency=>high valued private parts belonging to average joes=>userland tools will be required to be formally verified signed by an open community where everybody can speak up.

let me call cruftware vulnerable software of which one may assume backdoors are not purpousefully placed by their develloppers.

So everyday cruftware like flash (crammed chockfull with the latest newest gadgets and "enhanced user experiences") necessary for many sites, will have to choose between open source, and formal verification (think SPIN model checker), or closed source followed by a correlation of cruftware use and loss of digital savings ("what were you thinking running closed source software?").

I believe bitcoin will enhance the general computing experience.

If this happens having just one closed source service/software running could result in compromise. As more software gets formally verified for the public trust, less closed source software remain an avenue of attack, resulting in more attacks via such remaining software, resulting in thefts correlated with that piece of software.

Quickly the only used software will be open source.

Now all devellopers have a common interest (and have little motivation to develop closed source software that nobody will trust to run, i.e. the average programmer becomes politically awake). A large mass of developers will need to work out a global creativity reward system (Until they develop this, they see little use in coding at all)

Btw, has anybody ever set breakpoints and traced control flow of different official bitcoin client versions upon processing the strange transactions as seen on http://blockexplorer.com/ ?

[Litt]

a user friendly way to secure the wallet for the masses is in the works I believe at some level. I'm sure most are capable of doing this by yourself here now, but that certainly won't be the case in the future.

[Hans0]

publickeyhash, you are right in all regards concerning future trends. But this will take 5 years or so. We cannot wait.

You are also right that the keys must exist in ram for a split-second. This can never be prevented. However the risk can be reduced by increasing the required effort. And you are completely safe as long as you do not do transactions.

Bitcoin must be user-friendly under all circumstances in order for it to become popular and for our existing coins to make us rich. Every dollar entrusted to bitcoin increases the price. We must further that trend by eliminating all geeky concerns from the end-users life.

[Gavin Andresen]

The current plan is to password-protect private keys in the wallet and unlock them when coins are sent (with an option to 'remember the password' for a certain period of time) for the 0.4 release.

That doesn't completely fix the problem (a keystroke logger can get your password, and a virus can insert itself so instead of sending 10 BTC to your grandma in Boise it makes bitcoin send your entire wallet balance to Little Bobby Blackhat).

To almost completely fix the problem transactions would need to be created on one device and then verified on a second device.  Assuming both devices aren't infected/compromised, that will be safe. The two devices would be your computer and something else-- maybe a website, If anybody has experience with that type of cross-device security/programming and is interested in helping Bitcoin out, help would be much appreciated.

[lizthegrey]

The first thing to implement would be the ability to import a transaction from a file/transmit to the network, and to export a transaction to a file rather than transmitting it to the network. My fiancee and I are planning to do this for a python bitcoin implementation we're working on; this will reduce the temptation for people to attack holders of large wallets because theit wallet could be held on and transactions could be performed offline on an airgapped machine.

[Hans0]

Gavin, it is comforting that the project has this concern in mind. It think it is of highest importance that everyday joe can trust bitcoin to manage his whole wealth. That means it must not only be safe but also understandably and intuitively safe. I would very much like to see every household have 10% of their funds in bitcoins as that would provide a nice protection agains economy crisis or break-down.

I also like the two-machine approach very much because I can inspect the transaction on the USB stick to be correct. Maybe this should be an XML format so everyone can look into it without trusting the software? If I was to send 100k$ in bitcoins to buy a house I would make triple sure everything is alright.

[publickeyhash]

Perhaps the ecdsa signing code and private keys could reside on a smartcard?
How would a user be able to verify a transaction before signing it?
Can a setup be made that guarantees a transaction will be sent to the right person?
I am thinking about the small "calculator"format tokens. Could a custom 'token' display amount and target adress?

So like this: upon user attempt to send BTC a potentially infected pc proposes a transaction to the smartcard. The smart card stores the transaction and is ready to be switched off. The token restarts the smart card, and the smart card analyzes the transaction and outputs BTC amount and target adress to the token LCD. (the token has a button to accept or decline). Upon acceptance, the smarcard signs the transaction and stores it. Computer now starts up the smart card and can find the signed transaction only if user agreed.

Now that I think about it, perhaps the token should have a 2 row screen, one for amount and adress, and a full keypad. Create transactions on the smart card itself through the token.

Assuming the token is not programmable, it would be hard to hack, and since the token is never connected directly to PC, they would have to hack the smart card first...

[Maged]

Perhaps the ecdsa signing code and private keys could reside on a smartcard?
How would a user be able to verify a transaction before signing it?
Can a setup be made that guarantees a transaction will be sent to the right person?
I am thinking about the small "calculator"format tokens. Could a custom 'token' display amount and target adress?

So like this: upon user attempt to send BTC a potentially infected pc proposes a transaction to the smartcard. The smart card stores the transaction and is ready to be switched off. The token restarts the smart card, and the smart card analyzes the transaction and outputs BTC amount and target adress to the token LCD. (the token has a button to accept or decline). Upon acceptance, the smarcard signs the transaction and stores it. Computer now starts up the smart card and can find the signed transaction only if user agreed.

Now that I think about it, perhaps the token should have a 2 row screen, one for amount and adress, and a full keypad. Create transactions on the smart card itself through the token.

Assuming the token is not programmable, it would be hard to hack, and since the token is never connected directly to PC, they would have to hack the smart card first...

I like this! It's like SmartSwipe for Bitcoins!