Topic: Multisig methods don't need multisig bitcoin to prevent thefts (Read 2148 times)
Multisig is good.
Absolutely -- almost by definition, singlesig means a single point of failure. It's a considerably harder target though -- how do you get the IP of a mobile phone? How do you get a remote shell on it sufficient that you can grab the private key? There is certainly mobile malware out there; but given the owner would know how serious it was they would probably not use it as their primary phone and wouldn't install any superfluous apps, and even if they did, how would the malware author target that specific phone?
Maybe I'm being a bit crazy here - you'll have to excuse me if I am - but would it be possible to create an ECC key pair where the private key is 2GB in size (that's 8589934592 bit) and the public key is only 256 bit?That's not how it works. Sorry.
Absolutely -- almost by definition, singlesig means a single point of failure. It's a considerably harder target though -- how do you get the IP of a mobile phone? How do you get a remote shell on it sufficient that you can grab the private key? There is certainly mobile malware out there; but given the owner would know how serious it was they would probably not use it as their primary phone and wouldn't install any superfluous apps, and even if they did, how would the malware author target that specific phone?
Maybe I'm being a bit crazy here - you'll have to excuse me if I am - but would it be possible to create an ECC key pair where the private key is 2GB in size (that's 8589934592 bit) and the public key is only 256 bit?We put this huge/normal-sized key pair on a machine that has limited bandwidth (let's say 2KB/s). If we do this, it would take an attacker 9 months to download the private key from the machine - regardless of whether he has root access or something worse. The only thing it can't protect from is if the attacker has physical access to the machine.
This server could send out transactions without problems. 2KB/s is like 8 transactions per second, using the average transaction size of 256 bytes. Plenty for most use cases. I don't know how long it would take to sign something with a key of this size though (let alone if it's even possible to have different sized public and private keys). This, CPU time, might be the bottleneck instead.
Am I being nutty? Of course, the attacker could just get the server to sign a transaction that pays out to his address. So maybe this is kind of pointless.
I don't disagree that it's possible; but I do disagree that it's as easy.
There were 8 hosts attacked; and the attacker isn't necessarily in the same country as, nor knows anything about the host owners. It's quite a leap to go from an IP address to gaingin access to a physical mobile phone is all I'm saying.
I agree that my hypothetical attack vector is, in general, probably more costly than the linode incident. I was more thinking about future. Security can't be merely looking backwards and closing the holes that already have been exploited. There were 8 hosts attacked; and the attacker isn't necessarily in the same country as, nor knows anything about the host owners. It's quite a leap to go from an IP address to gaingin access to a physical mobile phone is all I'm saying.
This is just a matter of ingenuity and timing. I was once in a close proximity of Slush's phone, he was sitting right behind me at the Prague Bitcoin conference. I sold him a Casascius coin and he paid me with his phone. I could have, hypothetically, used a bluetooth exploit or just shortly grabbed it while he wasn't paying attention, or trick him into lending me the phone for a couple of seconds. Or I could have put a spying device into the coin.
I don't disagree that it's possible; but I do disagree that it's as easy.
There were 8 hosts attacked; and the attacker isn't necessarily in the same country as, nor knows anything about the host owners. It's quite a leap to go from an IP address to gaingin access to a physical mobile phone is all I'm saying.
Absolutely -- almost by definition, singlesig means a single point of failure. It's a considerably harder target though -- how do you get the IP of a mobile phone? How do you get a remote shell on it sufficient that you can grab the private key? There is certainly mobile malware out there; but given the owner would know how serious it was they would probably not use it as their primary phone and wouldn't install any superfluous apps, and even if they did, how would the malware author target that specific phone?
This is just a matter of ingenuity and timing. I was once in a close proximity of Slush's phone, he was sitting right behind me at the Prague Bitcoin conference. I sold him a Casascius coin and he paid me with his phone. I could have, hypothetically, used a bluetooth exploit or just shortly grabbed it while he wasn't paying attention, or trick him into lending me the phone for a couple of seconds. Or I could have put a spying device into the coin.We have seen that the attacks were pretty narrowly targeted. Even narrower targeting like my imaginative example might be expected as Bitcoin becomes more widely spread and expensive. Incidents like this are very unfortunate, but hopefully at least the community will learn from them and standardised practices will emerge, akin to the PCI-DSS that's used by the credit card industry.
Your proposal also merely shifts the single point of failure. In that case, the attacker would not be attacking the Linode box but Zhou's / Slush's phone.
Absolutely -- almost by definition, singlesig means a single point of failure. It's a considerably harder target though -- how do you get the IP of a mobile phone? How do you get a remote shell on it sufficient that you can grab the private key? There is certainly mobile malware out there; but given the owner would know how serious it was they would probably not use it as their primary phone and wouldn't install any superfluous apps, and even if they did, how would the malware author target that specific phone?
But I think that we both agree with your premise, in that multisig is not necessary for prevention of issues like this.
Yep; we certainly do.
I don't think that encryption would help at all in the case of a system set up for automated transactions. It would only help if the rpc interface knows which process is making the call and only allows the process that unlocked a wallet to do transactions. I haven't really researched that but my understanding right now is that rpc calls wouldn't pass process id info.
There may be ways to utilize bitcoind so that the encryption protects the wallet but in the case that some valid script makes an localhost http based rpc call to send a payment out it would work just as well when the hacker made an rpc to send a payment. In other words, once the wallet is unlocked via rpc any process on the system has access to the open wallet.
There may be ways to utilize bitcoind so that the encryption protects the wallet but in the case that some valid script makes an localhost http based rpc call to send a payment out it would work just as well when the hacker made an rpc to send a payment. In other words, once the wallet is unlocked via rpc any process on the system has access to the open wallet.
I wasn't really saying one would use "read". I only suggested it because it was the quickest example to show how to corrupt your proposed command line.
This is all fine. I wasn't trying to provide an ultimate solution, but one that's simple and closes this attack vector.That's all by the by though really. My point was that your solution is vulnerable once the attacker has root (just as the existing setup was); my suggestion of external signing (and runeks suggestion of a tor-connected signing server is superb) isn't.
Your proposal also merely shifts the single point of failure. In that case, the attacker would not be attacking the Linode box but Zhou's / Slush's phone.But I think that we both agree with your premise, in that multisig is not necessary for prevention of issues like this.
Would it be possible to sign transactions on a completely different host to the machine that is publishing them to the bitcoin network? If this is possible then the machine that signs the transactions can be a completely isolated piece of kit, accessible only via a fraud detection proxy.
Yes I think so. That's what we're talking about as the "signing host". It is even conceivable that that host would maintain a shadow copy of the accounts database. It would therefore know the maximum that any one account holds. Any request for a signature of a transaction with higher than that value would be obviously bogus.
Would it be possible to sign transactions on a completely different host to the machine that is publishing them to the bitcoin network? If this is possible then the machine that signs the transactions can be a completely isolated piece of kit, accessible only via a fraud detection proxy.
If it knew the output addresses for each user then it could generate all the transactions it needs and keep them in RAM, this way the "release funds" part is completely separate from the "sign transactions" part and could be much harder to take control over.
If it knew the output addresses for each user then it could generate all the transactions it needs and keep them in RAM, this way the "release funds" part is completely separate from the "sign transactions" part and could be much harder to take control over.
What you describe is a more difficult attack. Linux typically has "read" as a bash builtin so the attack would need to work slightly differently. A normal sysadmin notices when the machine was rebooted and/or files modified. If he's paranoid, he'd restore from backups onto a fresh VM if he sees this happening.
I wasn't really saying one would use "read". I only suggested it because it was the quickest example to show how to corrupt your proposed command line.
The best hack of that sort would be, I think, to replace bitcoind itself. Perhaps with a version that waited for the decryption password and then emailed you a copy of all the private keys.
I'm not so sure that sysadmins notice when files are modified. Depends whether they've got an IDS installed.
That's all by the by though really. My point was that your solution is vulnerable once the attacker has root (just as the existing setup was); my suggestion of external signing (and runeks suggestion of a tor-connected signing server is superb) isn't.
I've got an additional idea on top of runeks': the Tor node would connect to the public server rather than vice versa. Then every port on the signing server could be closed.
This was my exact thought when I saw the article on Ars and Gavin's comment in the article. Right now - without multi-sig - it's a simple as sending the unsigned transaction to a second server (possibly connected to the internet via Tor to hide its location) and letting this second server "scrutinize" the transaction, as Gavin puts it, before signing. The only thing multi-signature transactions do is increase the number of devices that need to be hacked, in order to gain control over the coins. This example of "scrutinizing" transactions is just as possible with single-signature transactions.
With regards to scrutinizing, it will always be a balance of security and functionality. Bitcoinica can't scrutinize transactions and prevent transactions of more than, for example, 10,000 BTC from being approves, without preventing Bitcoinica users from withdrawing more than 10,000 BTC at a time.
With regards to scrutinizing, it will always be a balance of security and functionality. Bitcoinica can't scrutinize transactions and prevent transactions of more than, for example, 10,000 BTC from being approves, without preventing Bitcoinica users from withdrawing more than 10,000 BTC at a time.
I suppose; but if they've got root access then installing a handy "/usr/bin/read" that emails them everything that is sent wouldn't be too hard.
Oh sure, it doesn't protect against all attacks. Once the attacker has root, he can read/modify anything. But my point is that having a root password shouldn't be sufficient to steal the bitcoins.What you describe is a more difficult attack. Linux typically has "read" as a bash builtin so the attack would need to work slightly differently. A normal sysadmin notices when the machine was rebooted and/or files modified. If he's paranoid, he'd restore from backups onto a fresh VM if he sees this happening.
Even a normal wallet encryption, which is already available, would have prevented this theft. ...
This way the password does not show up in bash history and you don't need a gui or a custom tool to unlock it.
Code:
read -s -p "Pwd: " pwd;bitcoind walletpassphrase $pwd 2000000000
This way the password does not show up in bash history and you don't need a gui or a custom tool to unlock it.
I suppose; but if they've got root access then installing a handy "/usr/bin/read" that emails them everything that is sent wouldn't be too hard.
The key part of the protection is that it's done by another system.
With multisig, will it not be possible to have two independent servers, where each of them can sign a transaction, but checks that it makes sense first? This is a solution which is both fully automated and more secure than keeping keys on a single server, even if encrypted.
Yes; definitely multisig will help.
I'm merely pointing out that a large part of the multisig method of protection will work just fine without it.
With multisig, will it not be possible to have two independent servers, where each of them can sign a transaction, but checks that it makes sense first? This is a solution which is both fully automated and more secure than keeping keys on a single server, even if encrypted.
Also there could be a multi-tiered approach. The hot server will have a small amount of coins for immediate use, requiring just local keys. In addition a larger amount of coins will be in a 2-of-2 address with keys in the hot server and a lukewarm server (which is more secure than just a key in the lukewarm server). If the hot server is close to running out, he polls the lukewarm server to send it some coins, which it will agree to only if the transaction makes sense, is in a limited amount, and it notifies the operator. This obviates the need for manual intervention in each and every transfer, while still offering damage control.
Also there could be a multi-tiered approach. The hot server will have a small amount of coins for immediate use, requiring just local keys. In addition a larger amount of coins will be in a 2-of-2 address with keys in the hot server and a lukewarm server (which is more secure than just a key in the lukewarm server). If the hot server is close to running out, he polls the lukewarm server to send it some coins, which it will agree to only if the transaction makes sense, is in a limited amount, and it notifies the operator. This obviates the need for manual intervention in each and every transfer, while still offering damage control.
Even a normal wallet encryption, which is already available, would have prevented this theft. After a boot, the legitimate user would just unlock the wallet in memory for the maximum possible time. Looking at the source, the parameter is currently handled as int, which means like 60 years even on a 32bit platform. Resetting the root password or rebooting does not compromise the wallet security. Unlocking from commandline is easy:
This way the password does not show up in bash history and you don't need a gui or a custom tool to unlock it.
Of course, it does not defeat more sophisticated attacking methods, such as a tty sniffer, using RPC directly and so on. But the most obvious one and the one apparently used most often, copying of the wallet file, would have been prevented.
Code:
read -s -p "Pwd: " pwd;bitcoind walletpassphrase $pwd 2000000000
This way the password does not show up in bash history and you don't need a gui or a custom tool to unlock it.
Of course, it does not defeat more sophisticated attacking methods, such as a tty sniffer, using RPC directly and so on. But the most obvious one and the one apparently used most often, copying of the wallet file, would have been prevented.
People are talking about multisig support as if it would have prevented the recent thefts. It probably would have; but it would be nothing to do with multisig. That same security is (mostly) already available.
Here's what Gavin said in the Ars Technica article:
In other words: a second secure machine is needed to approve a transaction. Let's say it's as simple as a message popping up on your mobile phone saying "approve the following withdrawals". In multisig, answering "yes" would sign the transaction with the second private key. That would definitely be great. However, what is to stop the single current signature required being obtained in the same way it will be in this multisig world?
No private key stored on the "hot" wallet; the mobile phone app stores the private key and signs on demand with approval from the owner. Now imagine that that app was in Zhou or slush's pocket.
This is not to say there aren't additional advantages to multisig (prevention of damage on theft of mobile phone being one), but the above would have prevented the thefts without needing multisig support to be ready.
There are already people doing this: BCCAPI as used by BitcoinSpinner, Electrum, StrongCoin, Blockchain.info -- they all do off-server transaction signing.
Here's what Gavin said in the Ars Technica article:
Quote
Under the new system, wallets would contain only one of two private encryption keys needed to spend coins. The other key would reside on a separate machine at a different location. Software on the second machine would scrutinize proposed transactions to make sure they're legitimate, and wouldn't send an entire payment all at once.
In other words: a second secure machine is needed to approve a transaction. Let's say it's as simple as a message popping up on your mobile phone saying "approve the following withdrawals". In multisig, answering "yes" would sign the transaction with the second private key. That would definitely be great. However, what is to stop the single current signature required being obtained in the same way it will be in this multisig world?
No private key stored on the "hot" wallet; the mobile phone app stores the private key and signs on demand with approval from the owner. Now imagine that that app was in Zhou or slush's pocket.
This is not to say there aren't additional advantages to multisig (prevention of damage on theft of mobile phone being one), but the above would have prevented the thefts without needing multisig support to be ready.
There are already people doing this: BCCAPI as used by BitcoinSpinner, Electrum, StrongCoin, Blockchain.info -- they all do off-server transaction signing.
Jump to: