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

Question

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.)

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

The answer is client side encryption.

Basically it works something like this.

1. You register with the e-wallet service.
2. CLIENT - You then create your first Bitcoin key pair. This is done with Javascript running in the browser.
3. CLIENT - You are asked for a strong password to secure this key pair.
4. CLIENT - The private key is encrypted in the client with Javascript.
5. 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.

1. Select the Bitcoin keypair to spend from.
2. CLIENT - You are asked for the password to decrypt the private key. Again this is done client side.
3. CLIENT - The payment transaction is signed. (In the browser)
4. 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.

1. 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.

2. 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.

3. 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.

4. 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.