Creating a 2-3 MultiSig address from server script

[antonimasso]

Hello,

I want to create a MultiSig address where user A sends the public key of its bitcoin address (gets saved in the database). User B gets notified that he must send his public key to create the 2-3 MultiSig address. The third address is provided by me as a mediator. My concern is that if the server is hacked, the hacker can change my source code (PHP) so that 2 of 3 public keys are in his possession. Any ideas on how I can secure this 2-3 MultiSig address creation scenario?

Thanks

[amaclin]

I want to create a MultiSig address where user A sends the public key of its bitcoin address (gets saved in the database). User B gets notified that he must send his public key to create the 2-3 MultiSig address. The third address is provided by me as a mediator. My concern is that if the server is hacked, the hacker can change my source code (PHP) so that 2 of 3 public keys are in his possession. Any ideas on how I can secure this 2-3 MultiSig address creation scenario?

It is not a problem for a public keys
If you are afraid of sever hack you should not keep your private key on server

[antonimasso]

My private key is never stored in the server. My concern is that if the server is hacked, the hacker can alter the script so that 2 of the 3 public keys are his. If the user then sends bitcoins to that MultiSig address, the hacker has complete control of those bitcoins.

[amaclin]

My private key is never stored in the server. My concern is that if the server is hacked, the hacker can alter the script so that 2 of the 3 public keys are his. If the user then sends bitcoins to that MultiSig address, the hacker has complete control of those bitcoins.

No. He should have 2-of-3 signatures (private keys) to spend funds. Not public keys. All three public keys already known on the stage of generation msig address

[antonimasso]

I think you don't understand my question.
There are 3 users who will use their public keys to generate the MultiSig address.

User A -> Sends public key
User B -> Sends public key
I use my own public key

My concern is that if my server gets hacked, the hacker can change the script so:

User A -> Sends public key
Hacker inserts his two public keys and generates a MultiSig address. User A does not know the server was hacked and transfers bitcoins to that address. Since the hacker has the private keys of two of the public keys he can transfer those bitcoins to an address he owns.

[amaclin]

I think you don't understand my question.
There are 3 users who will use their public keys to generate the MultiSig address.

User A -> Sends public key
User B -> Sends public key
I use my own public key

My concern is that if my server gets hacked, the hacker can change the script so:

User A -> Sends public key
Hacker inserts his two public keys and generates a MultiSig address. User A does not know the server was hacked and transfers bitcoins to that address. Since the hacker has the private keys of two of the public keys he can transfer those bitcoins to an address he owns.

Who is funding the msig address? One of users will see that this address was not created with his public key.

[antonimasso]

User A funds this key. He can verify the redeemScript to see his address is still there, but will not know that the other two address have been modified.

[Envrin]

You can't, really.  If you a hacker manages to root the server, then any / all security measures you've built in to the software no longer matter.

So obviously, the first thing to do is make sure your server is locked down properly, fully updated, etc.  Then there's various other precautions you can take.  For example, it's it's PHP put the code in ionCube, look into using dnotify which will execute a script anytime a file is modified, hash the files and have them periodically scanned via crontab to see if they've been modified, add bait & kill switches to your system with hopes the hackers triggers one of those first, etc.

Again though, if they manage to root your server, and / all security precautions no longer matter.  That doesn't mean you shouldn't add them in though, because every little bit helps.

[Yoghurt114]

A user shouldn't send anything to such an address unless it knows all participants have their public key in there.

In other words, ideally, user A needs to somehow communicate with user B and verify the keys are correct.

If you, as a mediator, have sole knowledge about the public keys of the other participants in a transaction you are supposed to mediate, you are not a mediator but a mere proxy which requires trust not to fuck up.

[antonimasso]

Thanks for all your comments. I guess there is no way to make this script hacker proof. I'll have to secure my linux server and hopefully catch in time the attacker.

[etotheipi]

Thanks for all your comments. I guess there is no way to make this script hacker proof. I'll have to secure my linux server and hopefully catch in time the attacker.

There is a software solution, but it requires extra infrastructure and complexity to make it work.  The gist of it is that you will always provide addresses from a BIP32/HD Wallet chain.  You setup all parties to know the root public key of that chain and the software will recognize it (but not the chaincode!).  Then when the multisig script is received by the users' software, it can come with the multiplier that can be applied to the root public key.  If the included key that supposedly belongs to you match pre-verified root public key (EC-multiply) multiplier, then the user knows that the public key is truly owned by you.  Due to the difficulty of the discrete logarithm problem, and attacker has no way to produce a valid multiplier that, when applied to the already-verified root public key, produces his malicious address.  And without the multiplier, the software will prevent users from trusting that key.

This is something we had hoped to build (slowly) into Armory -- a way to create localized webs of trust so that you can pre-verify a root public key, and then the party can optionally choose to reveal a multiplier that proves a given address is part of his wallet.  This would be strictly optional, and none of the information reveals any other keys that party controls.

[antonimasso]

Could this be done in Javascript? I want to generate all private keys client side. I want my users to control their private keys and their bitcoins.

Thanks

[etotheipi]

Could this be done in Javascript? I want to generate all private keys client side. I want my users to control their private keys and their bitcoins.

Thanks

What I posted is mostly theoretical, unless you're going to have the users run your software, or you team up with wallet developers and standardize what I described above.  The users still maintain full control of their own private keys, but it gives them the ability (and yourself) to provide an extra piece of metadata with your addresses that proves the address is controlled by you.  More specifically, you publicly link a root public key to your identity, and then you can provide unique addresses to users for whatever purpose (in this case, for multi-sig signing authority) and the users will be able to verify that unique address actually belongs to you without them knowing any other addresses in your wallet.

We are helping some organizations get setup with Armory as their backbone, and had planned to demo this in localized environments, mainly to ensure that users within an organization can recognize the addresses of other users/branches of their organization.  We hope that we can make it a supported standard someday, as it has phenomenal security and privacy properties, and perfectly compatible with BIP 32.  But at the moment, it will have to be developed and deployed in isolated environments until it catches on.

[fbueller]

antinomasso - you should look into Bitcore or BitcoinJS. bitcoinJS is around longer, and made a big release lately.. Bitcore is taking off, and I'm using it at the moment.

If 12/24 word seeds are ok, maybe use BIP39 to generate a seed in the browser? Or, use some appropriate stretching function, and then create a hierarchical key, and submit the public key to the server? That way you can generate the multisig script on the server side, and do what you want with it.

https://github.com/bitpay/bitcore/blob/master/test/test.BIP39.js
https://github.com/bitpay/bitcore/blob/master/examples/HierarchicalKey.js
https://github.com/bitpay/bitcore/blob/master/examples/CreateAndSignTx-PayToScriptHash.js

If you're looking for a PHP library to handle BIP32, or raw transactions, or signing, you might find mine of some use: https://github.com/Bit-Wasp/bitcoin-lib-php

I am actually writing up a BIP similar to BIP70 to pair multisig wallets to a server in possession of all the public keys, allowing such requests to be certified, (and to request signatures given inputs & outputs) but that would only apply to apps I guess.

[antonimasso]

fbueller: What happens if your server is hacked and those public keys are modified with keys that belong to him? The server side script will be generating MultiSig addresses with 2 of 3 public keys belonging to the hacker.

[etotheipi]

fbueller: What happens if your server is hacked and those public keys are modified with keys that belong to him? The server side script will be generating MultiSig addresses with 2 of 3 public keys belonging to the hacker.

So far, people seem oblivious to this particular attack vector being investigated by antonimasso.  You can have the most hardcore security setup in the world, with an offline laptop buried 100 meters under Fort Knox, but none of it matters if the money destined to be stored there never makes it because an attacker swapped your deposit address. 

There are three primary issues at hand:

• How to get money into secure storage
• How to keep money secure once it's there
• How to securely authorize movement of money

The second one is where people are mostly focused.  The first and third are the ones that are subject to address manipulation, and provide a channel for an attacker to completely sidestep your cold storage.  The attacker can't get the money that's already in the secure storage, but he try to divert new money on its way there, or divert money leaving the secure storage all by manipulating network traffic or compromising devices that distribute addresses.

The payment protocol defends against man-in-the-middle attacks, but it still doesn't defend against your own server with the watch-only wallet getting hacked.  With the payment protocol, each address needs to be signed by an X509 cert on the same server distributing the addresses.  If an attacker gets control of that, he also can sign his own addresses to make them look legit. 

The technique I proposed allows one to provide a "fingerprint" of your offline wallet with every address, so that the other parties can verify your addresses if even your own address-distribution system is compromised.  Unfortunately, the infrastructure is not there to support it, but I hope we can eventually develop such a system.

[Envrin]

The payment protocol defends against man-in-the-middle attacks, but it still doesn't defend against your own server with the watch-only wallet getting hacked.  With the payment protocol, each address needs to be signed by an X509 cert on the same server distributing the addresses.  If an attacker gets control of that, he also can sign his own addresses to make them look legit.

Good point, and I'm not sure how to resolve that with existing protocol / infrastructure.  From a web wallet prospective, few off-the-cuff ideas:

1.) Require users to input their BIP32 public key each time they want to generate an address, but obviously that wouldn't go over well.

2.) Encrypt public key via AES256 with the user's wallet password, which isn't stored online.  Little inconvenient, because they need to enter their wallet password each time they want to generate an address, but would work decently.  If a hacker replaces the public key with something, then it's not going to decrypt properly unless they also know the user's wallet password.

3.) Have a separate server that holds checksum values of each BIP32 public master key, and bounce validation messages off it.  Pretty weak though, as if the hacker is in the server, they can easily see and bypass this one.

4.) Upon address generation, randomly check against a few previously created addresses to ensure they match the public key being used.  Plus maybe randomly call up a few previous transactions from the blockchain, and check the redeem script on them to ensure the public key matches up.  Hardly fool-proof, but it does make it a little harder as instead of just modifying the public key, they need to modify all addresses and transactions associated with the user account as well.

I don't know, will have to think about this more.