Topic: Split keys for secure handling on possibly-rooted devices (Read 1540 times)

Docs? Docs? Where are these docs of which you speak?

Yes, you're right, it's not supported by the code today. A patch to make it so would be quite nice to have, but it'd take careful design. The crypto isn't so hard. It's coming up with a good UI that allows you to synchronize the two (or more) independent clients in an understandable way.

Really? That feature may exist in the protocol, but (a) I didn't see it when I read the docs, and (b) it doesn't seem to have any client support. The implementation details aren't really important to me; I just want to be able to generate a receiving address via a trustworthy two-device protocol such that both devices (or an override key) are required to spend.

caveden: Actually, this would make it so that an attacker would have to get keys off two separate devices, not just a user password. There would be an override password, but because that password isn't necessary for normal transactions, it could be kept in a bank deposit box and forgotten, eliminating most of the risk of it being stolen.

markm: Yes, this would also be useful to organizations that want to keep their employees from spending or stealing their funds.

What if the so called "third party" is simply another department of an enterprise?

Might this be useful within enterprises for internal security against individual employees or small conspiracies of employees subverting the enterprise's bitfinances?

Maybe even cases where the type of "rooting" going on is that the individual having the "root" password to a particular machine or departmental pool of machines contemplates embezzling?

-MarkM-

Bitcoin allows you to lock up coins such that more than one signature is required to spend them.

The idea is good, but relying on a third-party service boils down to relying in the user capacity to protect his password. Actually, the same applies to any sort of encryption. That's the greatest problem, IMHO.

I think that the best way to secure something is to have a dedicated device for it. A sort of small smartphone that's not actually a phone, just a device to run a bitcoin client. Its connection to the internet would be limited to the bitcoin protocol and nothing else, no browser or anything that could compromise its security. No interaction with other computers, except through the bitcoin protocol.

Maybe someday we'll see someone manufacturing such device.

I originally posted this on Less Wrong at http://lesswrong.com/r/discussion/lw/5rg/homomorphic_encryption_and_bitcoin/ , but that probably wasn't the right place for it.

I've been thinking a lot about BitCoin recently, and particularly about BitCoin's main weakness: if your computer is compromised, an attacker could copy your BitCoin wallet and use it to steal coins. That's bad. But I've come up with a possible improvement that would greatly mitigate this risk, and was hoping for some help confirming its viability and filling in the details.

The basic idea is to make it so that rather than having a single computer which can steal your coins if it's compromised, you have two computers (or a computer and a phone), such that your coins can only be spent if both devices cooperate. It is much harder to break into two computers belonging to the same person than just one, so this makes coins harder to steal. You could also have one of the computers involved be a third party that you trust to keep its files secure, and while that third party would be able to freeze your funds, it wouldn't be able to steal them. Using a third party this way, you could also add withdrawal rate limits and time delays, further improving security.

I believe that this can be done in a fully backwards-compatible way, without any changes to the BitCoin protocol, using homomorphic encryption. BitCoin is based on elliptic curve cryptography; a receiving address is a public key, and a wallet file is a collection of private keys. The goal is to create a protocol where two cooperating computers produce a split key, such that they can use it cooperatively to sign transactions later, but neither one can sign transactions or determine the whole key on its own. My understanding is that homomorphic encryption can be used to implement a simulated computer that does arbitrary trusted computation, so this should be possible. However, I'm a bit fuzzy on the details, and I don't have the time or comparative advantage to implement this myself.

(To deal with the risk of one one computer being lost or damaged, there could also be an override key; both computers would have the public half of the override key, and the private half would be kept offline in a bank deposit box or something similar. Then both computers use the override key to encrypt their halves of the split key, and send the encrypted keys to a cloud backup provider.)

paulfchristiano pointed out that this doesn't actually require homomorphic encryption, only secure 2-party computation, which apparently is easier. In any case, I think this is fairly important; end users aren't very good at keeping their computers secure, and one incident of a botnet stealing all the coins it can find would be a major disaster.