How can a single person operation keep a collection of online wallets secure?

While this question is similar to others about securing wallets, I think it merits a question of it's own.

One thing that has dissuaded me in the past from running an online wallet service of some kind is the worry that I could be compromised (rubber hose, extortion, intimidation etc) and by extension permit full access to a large collection of bitcoins that I don't own. If I'm running an operation with potentially millions of dollars worth of bitcoins and my contact details become known (not that hard to find really) then I'm naturally a risk to my clients.

I've heard of multi-key encryption so that no one person has complete access (client PIN etc), but I'm not sure if that would solve the problem.

So my question becomes how can a single person operation ensure that they are unable to compromise the wallets under their care? Ideally the answer would not require any technical knowledge on behalf of the client beyond a passphrase.

(If such an approach became commonplace then it could act as a deterrent because attackers would simply see that the website uses that approach and slink away.)

Gary Rowe

Posted 2011-09-03T17:05:48.737

Reputation: 7 175

I've decided to go with @Fellow Traveler for the accepted answer in light of the work s/he has done in the area. I thought I'd add some of my thinking to the answers under a community wiki to allow others to help grow the solution. Once I'm happy with the first draft, I'll post it up (should be in a day or so). I'd like to thank everyone for their efforts with this tricky question. – Gary Rowe – 2011-09-12T17:27:51.553

This draft is much harder than it first appears, so I've appealed for help from the crypto exchange folks: http://crypto.stackexchange.com/q/746/812

– Gary Rowe – 2011-09-22T21:28:12.577

It would appear that there is a way, involving shared secrets, OpenID and a bunch of co-operating nodes. Work is ongoing to solve this problem. – Gary Rowe – 2011-10-15T00:39:13.360

Couldn't this be done with client side encryption? You could create a software to access your service that encrypts/decrypt client side. You would have no way to access the client's coins without knowing the passphrase. Wuala uses something like this for encrypted online storage. You must launch a Java applet from the browser to access your files.

– nmat – 2011-09-04T14:22:15.070

@nmat I was hoping to avoid the need for this kind of requirement by the client. – Gary Rowe – 2011-09-05T10:32:38.060

Been reading around this subject over on the Security SE blog and found this entry: http://security.blogoverflow.com/2011/08/12/qotw5-defending-your-website/

– Gary Rowe – 2011-09-06T22:17:27.253

And another one: http://security.stackexchange.com/questions/3584/how-do-you-compare-risks-from-your-websites-physical-perimeter-staff-etc

– Gary Rowe – 2011-09-06T22:22:51.180

Interesting approach by @Plato – Gary Rowe – 2011-09-08T06:22:25.447

Answers

My solution in Open-Transactions is to create a voting pool between participating transaction servers. (I noticed people discussing the project here so I wanted to make sure it's clear that this has only been proposed -- I haven't coded it yet.)

When Alice bails into an OT server, instead of sending her BTC directly to the server, she would send it to the voting pool.

===> My proposal was, whenever she wants to bail back OUT again, she sends a signed request to the server, and then she forwards the server's signed reply to the members of the pool. IF the pool members have a record/audit of Alice's account (which must be in a DHT they share) and IF the two signatures both verify on the receipt, and IF the request is within the allocation for that server and its maximum bailout-per-day, then the pool members vote ON THE BLOCKCHAIN to release the funds back to Alice.

===> This can also have a time delay on it, like a 24-hour bailout if necessary, and it is also subject to all pool members having access to audit data of the other pool members. (The other transaction servers.)

===> In the event where a server is HACKED, it will still be unable to move any of Alice's Bitcoins, because the other pool members won't vote for it without Alice's signature.

===> In the event where the server uses a dummy account (hidden from the DHT) to inflate the internal currency, the other pool members won't vote for such bailments out because it can't get past the real-time or daily audit.

===> In the event where a server refuses to answer Alice's bailout request, she can submit it to the pool members, which triggers a message to the offending server. If there is no reply, after a timeout, then they can vote 9 out of 10 (or whatever) to release the funds. This makes it possible to recover funds even from servers that have disappeared outright.

I work on OT in my spare time so it will easily be a few months before the above protocol is actually operational. But that's the basic plan.

Fellow Traveler

Posted 2011-09-03T17:05:48.737

Reputation: 597

+1 for the careful thinking. Would you mind explaining how "bailing" works in the context of the shared pool, and how currency inflation could take place? – Gary Rowe – 2011-09-12T12:33:10.460

It is possible, in Bitcoin, to send a transfer to a list of Bitcoin addresses, instead of to a single address. Then the recipients can vote (on the blockchain) to transfer the funds out again. This is made possible via the Bitcoin script language itself. Once the Open-Transactions side of the protocol is written, then it will take advantage of this built-in capability of Bitcoin. – Fellow Traveler – 2011-09-16T12:24:09.863

As long as the pool members make audit information available to each other (preferably in real time), then they will always know whether/when a server exceeds the amount of funds in circulation than it actually has in the pool. An OT server cannot normally change your balance, or forge any of your transactions, since it cannot forge your signature on the receipt. But the server COULD potentially create a "dummy" account (that it controls) and then sign FALSE RECEIPTS with that account, thus inflating the currency. BUT--this could NOT escape notice of the afore-mentioned audit protocol. – Fellow Traveler – 2011-09-16T12:28:01.373

This is a great goal, which many people will assume just can't be done. But remarkable strides are being made in the field of secure cloud computing via homomorphic encryption.

These schemes allow servers in the cloud to perform computing tasks (currently only a limited set of arithmetic) on encrypted values without decrypting them. See more at In what ways does Full or Partial Homomorphic Encryption benefit the cloud? - IT Security - Stack Exchange

A question about applying this to Bitcoin clients on Less Wrong is here: Homomorphic encryption and Bitcoin but they seem to be confusing homomorphic encryption with a form of secret splitting between two computers, which would not meet the goal outlined here.

I'm guessing that current homomorphic techniques are inadequate or too slow or both for bitcoin, but I'm not sure. But further research may make it practical.

nealmcb

Posted 2011-09-03T17:05:48.737

Reputation: 1 798

+1 this does indeed look promising. However this is far beyond the capabilities of the vast majority of startups. – Gary Rowe – 2011-09-04T19:43:50.660

Further explanation of Homomorphic Encryption: http://www.americanscientist.org/issues/pub/2012/5/alice-and-bob-in-cipherspace/1

– Gary Rowe – 2012-09-26T08:32:14.437

@Gary Indeed - as I noted the current state of the field probably renders it impossible or at least practical at this point. It is an open research area and currently it is beyond the capabilities of most researchers, if not all of them. – nealmcb – 2011-09-06T20:18:28.177

Then why post an answer that's not technically possible yet? – David Perry – 2011-09-08T14:59:22.670

2@david Even if it is not possible now, as I said, the OP describes a great goal. Bitcoin is new enough that people haven't always figured out how other technologies apply to it, or what lines of research should be pursued. This seems like a good line of inquiry to follow, and besides that is likely to be of interest to geeks that like bitcoin. – nealmcb – 2011-09-08T16:13:31.963

Fair enough, I suppose. – David Perry – 2011-09-08T16:40:34.963

One piece of technology that may provide an answer lies in federated servers, made possible by fellowtraveller's Open Transactions libraries. This is the same M of N signing that David Perry is talking about in his answer.

As a small e-wallet provider, you would join up with some colleagues, forming a network of wallet operators.

Using the scripting capabilities of Bitcoin, user Alice can create a special transaction and post it to the blockchain. This transaction is basically an IOU - it has an expiration date, and some instructions. If the instructions are met before the transaction expires, the transaction takes place, and the Bitcoin network agrees that the money is transferred.

Alice can specify multiple parties (i.e. you and your colleagues) to be the executors of the IOU. Her script can say "I require 9 out of these 10 wallet servers to sign this transaction."

So, this collection of federated servers must reach a consensus to make the transaction happen. If one, two, or eight of the ten servers are hacked, or the operators are forced to reveal the keys entrusted to them, the attacker won't be able to spend Alice's bitcoins, because he won't have the consensus.

I encourage anyone interested to check out the github repo and contribute. Fellowtraveller has done all of this work on his own so far and needs help.

Plato

Posted 2011-09-03T17:05:48.737

Reputation: 119

+1 for what sounds exactly what what I'm looking for. You see, this is why I like Bitcoin so much - there is always a way. – Gary Rowe – 2011-09-08T06:19:55.030

Thinking about this a bit more it appears that some kind of back channel is required to inform others in the federation to sign or not. For example, what if I'm held hostage for a few days getting the passphrase beaten out of me. I can offer up a plausible deniability passphrase that releases some low value funds, but alerts others that I've been compromised so they stop confirming. However, this alerts the thieves and that's the end of me. – Gary Rowe – 2011-09-08T12:29:34.280

Even having some kind of pre-arranged transaction value/volume per hour type arrangement is no good because if I reveal I'm under duress I've got no bargaining position with the thieves. I must rely on an outside, automated process that I can't influence making the decision that my signature on the transactions remains valid. Perhaps I have to turn up in person somewhere secure to renew the signature every X days or it expires. X must be low. Even then the problem is that it may not be me directly being compromised, perhaps family instead. – Gary Rowe – 2011-09-08T12:50:11.937

An easy way around it is some kind of Bitcoin insurance for small businesses - that's pretty much what a traditional bank would do. – Gary Rowe – 2011-09-08T12:50:49.267

It all depends on your definition of what an online wallet is.

You can make an online wallet service where the server side only knows your public keys and does all the heavy lifting required to track the block chain including the bookkeeping necessary to determine which transactions belong to your wallet. The client side is the only entity that has your private keys, and is the only one who can spend coins. If the server side vanishes into thin air you can always take your private keys to another provider or import them into a classic client. This kind of online wallet requires you to have a small piece of client side software running, such as a smart phone.

The BCCAPI is an example of such a service.

Jan

Posted 2011-09-03T17:05:48.737

Reputation: 441

While certainly not as advanced as nealmcb's writeup of homomorphic encryption, a solution offering a reasonable level of security against "rubber-hose access" could be built via a combination of cold storage, M of N signing and plausible deniability passwords.

Basically, you keep most of your bitcoins in one or more offline wallets which are kept in a physical format at a secure location - in order to compromise those coins/wallets you would have to be coerced into physically travelling to that location which is much riskier to the thief than simply beating a password out of you. Second, if there were three "signers" on the main account and two of them were required to make a transfer, beating the passwords out of at least two of them is twice as hard as beating the passwords out of just one, especially if they are geographically distant. Finally, it would be a simple matter for many existing sites to make username/password combinations their unique constraint rather than just username. This would effectively allow users to create one or more "dummy" accounts that could be compromised without compromising their entire balance. Since they all share the same username it would be difficult to prove how many accounts someone had without a full compromise of the site itself, hence providing at least some level of plausible deniability.

David Perry

Posted 2011-09-03T17:05:48.737

Reputation: 13 848

Very interesting. I'll have to think through that quite carefully... – Gary Rowe – 2011-09-06T18:22:59.827

1The big one, in my opinion, is the "cold storage" option since it means that someone attempting a "rubber-hose attack" would have to force you to begin the withdrawal, then wait the 24-48 hours it takes to get coins out of cold storage and then force you to initiate a transfer; double the amount of coercion necessary and an exponential increase in time-on-scene (which no criminal wants) – David Perry – 2011-09-06T18:33:17.620

I wish I could give you a more helpful answer, but the truth is that this is a very hard problem. Part of the solution is to separate your Bitcoins into a "working stash" and a "storage unit". Bitcoins in the working stash are easy to access and can be manipulated fully automatically. Bitcoins in the storage unit require manual intervention to release. YOu keep the working stash as small as practical to reduce the risk of a compromise.

If you have a very large number of Bitcoins, you may need multiple levels of storage with different levels of security/inconvenience. The goal is to lock up as many Bitcoins as possible as tightly as possible because you only very rarely need them.

Ideally, the ultimate "storage unit" should be offline. When you need to get Bitcoins out of the vault, you create a transaction to take that number of Bitcoins out of the vault and transfer them to the working stash, returning the change to the vault. You then walk that transaction to the storage machine which signs it. You then walk the signed transaction back to the online machine that commits it to the network.

The idea is that the offline storage machine's sole purpose is to sign transactions. Everything else is done by other machines. (Make sure it displays the amount and destinations before it asks you to sign!)

This just presents the problem of how you secure the offline storage signing machine and what you do if it breaks. The latter problem is the easier one -- you can lock a paper copy of the master encryption key in a vault.

David Schwartz

Posted 2011-09-03T17:05:48.737

Reputation: 46 931

+1 for raising some of the practical difficulties involved with this. I just wish there were some way to automate the owner out of the process. – Gary Rowe – 2011-09-06T22:20:28.980

The answer is client side encryption.

Basically it works something like this.

You register with the e-wallet service.
CLIENT - You then create your first Bitcoin key pair. This is done with Javascript running in the browser.
CLIENT - You are asked for a strong password to secure this key pair.
CLIENT - The private key is encrypted in the client with Javascript.
SERVER - Finally the public key and the encrypted private key are sent to the server for storage.

The e-wallet service doesn't have access to your private keys.

When you need to spend coins from your address.

Select the Bitcoin keypair to spend from.
CLIENT - You are asked for the password to decrypt the private key. Again this is done client side.
CLIENT - The payment transaction is signed. (In the browser)
SERVER - The transaction is sent to the server and forwarded to the Bitcoin network.

Again the e-wallet service never sees your private key.

There are still risks with this approach.

Keyloggers or malware could capture the passwords you use to encrypt the key pairs. It would be prudent to use a browser on a clean operating system or on a system not prone to malware e.g. A Kindle.
You have to trust the e-wallet service to not change the Javascript and capture your passwords. An external 3rd party could validate the Javascript via checksums perhaps.
A server breach could allow an attacker to change the client side javascript. The service should provide it's own mechanism for verifying the integrity of the code delivered to the browser.
The wallet service should keep secure offsite backups.

This is the approach being taken by a number of new wallet services such as StrongCoin and BitcoinJS.

Ian Purton

Posted 2011-09-03T17:05:48.737

Reputation: 1 010

Thanks for your answer, but it's not quite what I'm looking for. Running the service this way still leaves me vulnerable to being forced to add malicious code which compromises my clients. They should not have to trust me. I want to be provably out of the loop. – Gary Rowe – 2011-09-14T16:26:50.593

Generally in the private industry, this isn't done. You trust that these industries do it right, but usually they don't. Security is difficult, really difficult. Securing against yourself (thumbscrew and rubberhose access :p) when you have direct access to the hardware makes it even harder.

You might have the client use a password that is not stored, but is used as an encryption key to secure their wallet, and only them providing that key would unlock it. Of course you could always intercept that key, plus you have access to the encrypted data and algorithm used.

Honestly I wouldn't trust any public wallets.

Evil Spork

Posted 2011-09-03T17:05:48.737

Reputation: 491

It's having access to the root of the box that is the fundamental problem. Once that is compromised then all else can follow. – Gary Rowe – 2011-09-03T18:36:08.913