Topic: Split private keys - page 3. (Read 17136 times)

Ok, rereading Gavin I see that "give me a call on big transactions" is the external device. Also, the "something I get in the mail" is an external device. I'm not sure it's worth going through all this, risking small transactions, getting telephone calls, relying on a 3rd party site, when you could just plug that something you get in the mail into your usb port and be quite secure from the start. The usb device could even auto-sign small transactions (no need to press the button) and keep track of how many transactions are being sent every day and notify you if something is weird. Someone mentioned that you can hack a $20 mp3 player and install your own software. It's already got a display, input device and usb plug.

If you did want to implement Gavin's idea, bitcoin already supports multisigned transactions. You'd require 2 of 3 signatures. One on your computer, one kept by the service, and one in the thing you get in the mail. The partially signed transaction would have to be sent to the online service for the 2nd signature, and the service would forward it to the bitcoin network.

You don't confirm the transaction.  What happens is that the service fails to confirm bogus transactions made in your name by your (pwn3d) computer.

But there is no approach in which you only need an external service and no external device. If the root-kit has control of your computer, you can't trust anything on the computer, not even an https connection to a trusted server. How will you confirm the transaction? Or is the root-kit confirming it for you? Or are you confirming it, but to the wrong address?

I think the idea of an external device is a good one, since it's much easier to secure than your home computer. You don't have to implement ECDSA on tiny hardware, there are already smartcards available with this capability.

Looks like the two approaches are completely different.

One doesn't require the user to have to buy/build any specialized hardware.  The other doesn't require the user to rely on an external service.

The bitcoin world is big enough for both approaches to make sense at different times or to different people.

And I must say that after looking into actually implementing ECDSA on tiny hardware, I'm really, really warming to Gavin's idea.

Hmm, if we have the device with the screen and button, why do we need the BitBank? Since the only way to spend any coins from your account is to see the recipient address and amount on the device, and confirm with the button, what does the BitBank bring to the table?

I agree about the user friendly addresses. That might be a major hacking vector in the future because people aren't good at visually identifying those addresses. Something graphical would allow humans to leverage our brains' impressive image processing and pattern recognition capabilities. A strategy of running some 2d transform on the address and turning it into a colorful picture might be cool. Of course then hackers would try to find an address that produces a similar looking image, but maybe it's possible to make that hard. Another good approach is to add whitelisted addresses to the device as you make payments. You could also have trusted services that provide whitelists and text mappings to addresses, kind of like https domains.

I think the right design is for a device that plugs in via USB, that provides a display and a button.

The device receives an encrypted/signed message containing a bit of text and a nonce. The text is displayed. The button simply sends the nonce back to the host in the clear (the confirmation).

If you want to send money to somebody via a BitBank, you go into the UI (or click a link that prefills the field) and enter:

1) The value
2) Optionally, a Bitcoin address (or public key)
3) An email address or domain name for the counterparty you're trying to pay, as in genjixs scheme

The BitBank (which we assume is secure) either challenges the counterparty to sign a nonce with the private key corresponding to the address/pubkey, to prove ownership. Or if no address was provided it just goes and retrieves one, eg via http.

The BitBank then encrypts/signs a message containing the friendly address, a browser plugin sends it on to the hardware which decrypts it. Note that the compromised host cannot see or change the message. It is displayed on the little LCD display and after checking it says what is expected, the user presses the button. The nonce is then sent back to the BitBank which uses it as confirmation of the transfer.

This is similar to but not the same as the smartcard based schemes used by regular banks. Actually hosting the wallet or private keys on a smartcard doesn't make much sense, because the vulnerability is still in the display/input systems. And typing an address into a bank style calculator also doesn't make any sense because a virus could rewrite the address to be one of its own.

So I claim to be able to safely transact on a machine rooted by an arbitrarily skilled/motivated opponent, you need all of: a secure remote wallet, a secure display/input system (lcd display+button), user readable addresses. This would actually be MORE secure than the best banking security available today, because even 2-factor signing of wire transfers can fail if you get the bank wire instructions via a compromised host (they could be rewritten to be somebody elses bank account without you noticing).

The technologies you need to create the little display+button device are all pretty cheap, so I'm sure this will happen at some point. On the software side what's needed is a transition to user-friendly addresses rather than hash160s, and a challenge or pubkey request protocol.

This sounds a lot like threshold cryptography combined with distributed key generation.

There have been a few papers written on using RSA to achieve the same result, but I'm unaware of this being done with elliptic curves. However, I'm not a cryptographer.

As a sidenote, splitting a private key in this fashion could be used to construct a simple contract without needing a trusted third party. Two individuals could generate a split private key, and then sign a pure function that would perform some prearranged task; by signing the function, it would be tied to a bitcoin account and essentially act as a fund manager. Bitcoin miners could then run this pure function (passing into it the current block data as an argument) as part of the block chain verification process.

Here's a use case I'd like to work:

I tell Bitcoin running on my computer or cell phone to run transactions through a bitcoin security service-- maybe I give it a https:// URL for the service.

I tell the security service "auto-approve small-value transactions, but give me a call for any transactions above $X (or $XY per day)."

The security service sends me something in the mail that I keep safe, but that I can use to recover use of my bitcoins in case the security service goes out of business or disappears or I decide to stop paying for the service.

I get bitcoin addresses either from my bitcoin client (not trustworthy!) and/or from the security service that require both my computer and the security service to sign to spend.  And I have people send bitcoins (or I self-send my own bitcoins) to those addresses.

Spending coins is done as usual-- I type in an amount and an address.  Behind the scenes, magic happens, and if the transaction is greater than $X I get a phone call -- "Press 1 to confirm payment of $X bitcoins to bitcoin address blah, press 2 to cancel."

If I suddenly get random phone calls, I know my computer has been infected.

There are a number of possible solutions to this problem. The best solution from a technical point of view would involve an implementation of the paper I referred to earlier.

I gather that you are willing to make changes to the bitcoin client software to enable users to opt into some scheme whereby they are protected even if their computer is compromised.

If the computer running the bitcoin client is rootkitted then strictly, it's impossible to trust anything the computer displays or limit what it sends or ensure the security of any information you input. Practically, there are limits to the complexity of software which anyone is willing to develop for a rootkit and so some use of the computer may be possible.

Possible solutions are:

1) Facilitating the use of an offline secure computer to hold the private key and generate transactions. In this case the engineering effort goes towards implementing an efficient secure communication probably involving copying alphanumeric strings between the two computers. The user has to have another computer and be able securely to install the client.

2) Facilitating the use of a third-party website the approval of which (indicated by quoting an ECDS) would be required before transactions of the client could succeed. In this case, the unapproved transaction generated by the client is sent to the website, the website displays what the transaction would accomplish in some hard-to-spoof fashion and the user approves of the transaction via some hard-to-brute-force pre-arranged password or other such token. The website then signs and either passes the transaction back or sends the transaction onto the network itself. This is a solution which requires multisignatures to be enabled.

There are other solutions, none of them easy or nice.

It would be helpful if you could come up with some use-cases for the private key splitting. What ideally would you like the user experience to be? What degree of deviation and increased complexity from the normal transaction process do you imagine will be tolerable? Is this solution intended to be suitable for crypto-ignorant non technical users of bitcoin?

ByteCoin

The Ironkey also does RSA, it can be thought of as several devices in one, flash, smart card reader, smart card, all off a single USB bus.

The scenario we discuss here though doesn't require the flash component though it is of course interesting for other reasons.

As for the trusted input problem there are a few solutions, it depends on how deep you want to go to solve it.

To protect against user mode key l loggers in windows you can use the session 0 ui to collect the pin, only kernel malware would get past that.

You could use a secure PED (hard to do in a decentralized system)

You can use graphical pins, random layout (kind of like captchas)

There are a ton, first step IMHO is getting the keys off the host

Me too, and this is a likely attack in my opinion.

To protect against this attack one needs the keys to be in a crypto processor of some sort, and the ability to do some flavor of trusted pin presentment.

Though this would mitigate the risks significantly we would also want to have a recovery story in the event of token loss and theft.

Thanks, I'm a bit obsessed with that idea


I just checked the code again and I'm pretty sure it is a threshold scheme. nSigsCount is the threshold and nKeysCount is the total number of keys. Yes, it would have to be used by the sender of the coins to you. So, either you send yourself transactions like this, or you ask the person paying you to do a transaction like that. This could be as simple as giving them a different version of the bitcoin address that has a few type bits in it and a bunch of concatenated public keys. It would look like a regular address, just longer. You wouldn't even have to specify you want a special transaction, it would be implicit in the address.


Not if the rootkit has a keylogger in it. Also, it's better if the attacker doesn't get the encrypted wallet, because then the problem is reduced to how good your pass phrase is.

An encrypted wallet could protect a user completely compromised by a root-kit trojan.  I don't see how cutting and pasting an encrypted wallet over to a service (dropbox) or device (android phone) is any different than splitting keys.

The dead man's switch is a nice idea. 

Regarding script.cpp, I just checked if the opcode is there and not the logic. It looked to me that this is not a threshold scheme but a "you must present two signatures" scheme - so that's why I wrote about "increasing risk of loss". Moreover, wouldn't it also have to be used by the sender of the coins?!

Right, so by definition they don't have their wallet on the computer. IronKey has built in AES encryption. Imagine a smartcard or usb drive that had built in ECDSA encryption. The device could generate and store private keys and sign bitcoin transactions, but would be designed to never allow access to the private keys. The client just sends the unsigned transaction to the device and gets back the signed transaction.

This still has an weakness though. A rootkit could send the drive a transaction for your entire balance and have it sign it. So you need a screen on the drive that shows the amount and recipient address, and a physical confirm button.

The risk profile I care about is:

User's computer is completely compromised by a root-kit trojan, but they don't know it.

However, the user has access to some other device or service that they have setup in advance to be a "second line of defense" to prevent their entire wallet from being stolen.

I agree regarding risk profiles.

I known the iron key guys, it's a good product and the team they have is good but it's expensive and doesn't support ECC or at least it did not last year and I highly doubt it supports the curve bitcoin uses.

I think it would be possible to get the interesting scenarios to work on a cheap 10 device, initial probably being around 40 due to volume issues, the form factor doesn't need to be a card there are lots of USB dongles.

It really depends on how much money you're talking about. Split keys and dead man's switch don't really make sense for a few hundred bucks worth. But if you have $100,000 in bitcoin, do you really want to bet it all on one smartcard? We need to come up with different approaches for different risk profiles. Certainly, making it really simple to securely store $500 is very important.

I think a device like IronKey but with the ability to sign a bitcoin transaction would be great for this. It could be a smartcard too, but not everybody has a smartcard reader these days. I'm looking forward to bitcoin keyboards with a built-in smartcard reader. They could have a hardware override so that the keyboard stops sending input to the computer and is only used for unlocking the smartcard.

I have worked on systems that utilize key splitting in the past, though not with ECC.

I like key splitting but thought it might be worthwhile to play devils advocate and see where it takes us.

Usability of these systems are typically poor (complex and failure prone) but the nature of the systems that use this approach it's not been a problem, for Bitcoin I think it can be.

If the goal is to protect the key from compromise we might want to enumerate the threats we hope to mitigate, for example if it's the Trojan cases then the code that can steal one key could likely steal all keys.

Process and privlige separation helps address the key compromise cases, this can be done in a few ways for a software only solution you can imagine an authenticated service and a LPC or maybe one where crypto happens on a phone vs on the pc.

Another more common design pattern would be to move crypto to a smart card and have cards clone the crypto to a backup card to deal with the loss issue.

Well script.cpp is the core. It's completely integrated into bitcoin, it's just not in the default GUI. Before putting it into the GUI I'd add support to the RPC. I don't understand why this increases the risk of loss. If you only need 2 out of 5 keys, you can lose three of them and still be able to access your account. You can even do 1 out of 5 if you're worried about that and less worried about theft.


Well there's always a tradeoff between loss and theft. If you're worried about loss but not theft you'd want 1 out of n where n is big. If you're worried about theft and not loss you'd want n out of n. You're usually worried about both so you compromise and choose m out of n  somewhere in the middle.

I think a complimentary technique is to use a dead man's switch, so that in the case of loss Bitcoin will transfer your funds to another account after say 30 days. This is also already built into bitcoin scripting. That way you can focus less on loss and more about theft in your crypto protocol.