BitShares Forum

Main => Technical Support => Topic started by: crazybit on May 26, 2014, 04:16:01 pm

Title: AGS potential security issue
Post by: crazybit on May 26, 2014, 04:16:01 pm
One thing sure is that more and more DAC will come out in future,but there is a potential security issue that the more times we import the AGS private key to claim the corresponding shares in the DAC,the more risk the private key might be exposed,under the current social contract without AGS Liquid,we even cannot transfer the AGS shares to other address if the private key exposed,is there any consideration or plan to improve the AGS security,please discuss.
Title: Re: AGS potential security issue
Post by: santaclause102 on May 26, 2014, 04:24:48 pm
I don't think you expose your private keys to anyone else in the network. You just verify on your local machine to the network that you own the address that is granted shares...
Title: Re: AGS potential security issue
Post by: toast on May 26, 2014, 04:42:20 pm
I think he means a malicious client stealing private keys. Of course this is a great reason to make AGS liquid.

You can always sign transactions offline and refuse to use a client that doesn't allow you to construct unsigned transactions.
Title: 回复: Re: AGS potential security issue
Post by: crazybit on May 26, 2014, 04:45:33 pm
I don't think you expose your private keys to anyone else in the network. You just verify on your local machine to the network that you own the address that is granted shares...
you have to admit that it is possible your private key might be exposed if it is imported to the customized or malicious DAC client with the purpose to steal your private key.we cannot review every DAC client source code(i think mainly the third party DAC) and build client by ourselves to make sure the client will not steal our private key.
Title: Re: AGS potential security issue
Post by: crazybit on May 26, 2014, 05:01:46 pm
I think he means a malicious client stealing private keys. Of course this is a great reason to make AGS liquid.

You can always sign transactions offline and refuse to use a client that doesn't allow you to construct unsigned transactions.
Yes,you got my point of the security issue part,but i am not talking about liquid AGS,just concern for the AGS Security issue.
Title: Re: AGS potential security issue
Post by: bitmeat on May 26, 2014, 05:24:34 pm
The more times a private key is used to sign, the easier it is to hack the address. That's why Satoshi in his original paper recommends creating a new change address every time a transaction is signed. Real security is achieved if you ONLY sign things ONCE per private key.
Title: Re: AGS potential security issue
Post by: Overthetop on May 27, 2014, 07:11:28 am
How about this?

https://bitsharestalk.org/index.php?topic=4737.0
Title: Re: AGS potential security issue
Post by: toast on May 27, 2014, 01:44:59 pm
How about this?

https://bitsharestalk.org/index.php?topic=4737.0

How would that solve the problem?
Title: Re: AGS potential security issue
Post by: crazybit on May 31, 2014, 05:04:20 am
Inspired by logxing's proposal, i come up with an idea which may completely solve this potential security issue.  if we could use the signature which sign on the specified text(e.g the donation address) with private key, to claim the corresponding shares in different DACs,then we would not worry about private key stolen,as we do NOT need to expose our private key and use different signature to claim the shares in different DAC. e.g signature to claim the XTS shares =sign(“XTS”+Pts/BTC donation address, PrivateKey), signature to claim the DNS shares =sign(“DNS”+Pts/BTC donation address, PrivateKey)
Title: Re: AGS potential security issue
Post by: toast on May 31, 2014, 06:00:06 am
Inspired by logxing's proposal, i come up with an idea which may completely solve this potential security issue.  if we could use the signature which sign on the specified text(e.g the donation address) with private key, to claim the corresponding shares in different DACs,then we would not worry about private key stolen,as we do NOT need to expose our private key and use different signature to claim the shares in different DAC. e.g signature to claim the XTS shares =sign(“XTS”+Pts/BTC donation address, PrivateKey), signature to claim the DNS shares =sign(“DNS”+Pts/BTC donation address, PrivateKey)

Yep, we can have a dedicated tool just for this
Title: Re: AGS potential security issue
Post by: xeroc on May 31, 2014, 06:58:13 am
We disscused sth similar in the "Mirrorchain" thread .. you should take a look
Title: Re: AGS potential security issue
Post by: crazybit on May 31, 2014, 07:08:18 am
We disscused sth similar in the "Mirrorchain" thread .. you should take a look
Thx,i would take a look
Title: Re: AGS potential security issue
Post by: bitmeat on May 31, 2014, 07:38:13 am
Inspired by logxing's proposal, i come up with an idea which may completely solve this potential security issue.  if we could use the signature which sign on the specified text(e.g the donation address) with private key, to claim the corresponding shares in different DACs,then we would not worry about private key stolen,as we do NOT need to expose our private key and use different signature to claim the shares in different DAC. e.g signature to claim the XTS shares =sign(“XTS”+Pts/BTC donation address, PrivateKey), signature to claim the DNS shares =sign(“DNS”+Pts/BTC donation address, PrivateKey)

Awesome! I strongly prefer this method. This should be a standard tool in the toolkit. I would imagine we already have a tool that generates the genesis block.

One problem I see with this method however, is that it generates a signature, not a public address. i.e. only holders of AGS could generate the public address for each DAC.

Unless the DAC itself has a method of claiming by signature, but that may complicate the protocol.

Does the Bitshares framework support the same transaction OP_ codes as Bitcoin?
Title: Re: AGS potential security issue
Post by: toast on May 31, 2014, 02:08:48 pm
Inspired by logxing's proposal, i come up with an idea which may completely solve this potential security issue.  if we could use the signature which sign on the specified text(e.g the donation address) with private key, to claim the corresponding shares in different DACs,then we would not worry about private key stolen,as we do NOT need to expose our private key and use different signature to claim the shares in different DAC. e.g signature to claim the XTS shares =sign(“XTS”+Pts/BTC donation address, PrivateKey), signature to claim the DNS shares =sign(“DNS”+Pts/BTC donation address, PrivateKey)

Awesome! I strongly prefer this method. This should be a standard tool in the toolkit. I would imagine we already have a tool that generates the genesis block.

One problem I see with this method however, is that it generates a signature, not a public address. i.e. only holders of AGS could generate the public address for each DAC.

Unless the DAC itself has a method of claiming by signature, but that may complicate the protocol.

Does the Bitshares framework support the same transaction OP_ codes as Bitcoin?

>  only holders of AGS could generate the public address for each DAC.

Not true - you put the public keys in the genesis block like you do now, but to claim them you check the SIG(pubkey, "BTSX") instead of just SIG(pubkey).

We don't use OP_, we hard-code all needed transaction types for each DAC
Title: Re: AGS potential security issue
Post by: bitmeat on May 31, 2014, 03:37:35 pm
I see, then all the addresses use the SIG(pubkey, "BTSX"), right?
Title: Re: AGS potential security issue
Post by: bitmeat on June 02, 2014, 05:19:01 am
Final suggestion from me on making AGS liquid:

Why not make it so that if some minimal amount of BTC is sent to the ANGEL BTC address with a special message containing a valid BTC address, then it transfers over the AGS to the new address?

Then that amount can be kept as "transfer fee".

Of course, there could be complication for snapshots that are already taken. i.e. Feb 28 for the BTSX, would it still honor transfer AFTER the Feb 28 snapshot, or not, etc.
But nothing we couldn't implement easily. We already have tools to parse the transactions from AGS, just parse the messages as well.

Thoughts, comments?

UPDATE (examples):

FEB 1, 2014:
1SomeBTCAddressT56mDQzEdebQdibmigU-> 1ANGELwQwWxMmbdaSWhWLqBEtPTkWb8uDc | AMOUNT: 1 BTC

FEB 2, 2014:
1SomeBTCAddressT56mDQzEdebQdibmigU-> 1ANGELwQwWxMmbdaSWhWLqBEtPTkWb8uDc | AMOUNT: 1 BTC

APR 2, 2014:
1SomeBTCAddressT56mDQzEdebQdibmigU-> 1ANGELwQwWxMmbdaSWhWLqBEtPTkWb8uDc | AMOUNT: 3 BTC

JUNE 15, 2014:
1SomeBTCAddressT56mDQzEdebQdibmigU-> 1ANGELwQwWxMmbdaSWhWLqBEtPTkWb8uDc | AMOUNT: 0.02 BTC
MESSAGE: "TRANSFER TO 1AnotherBTCAddressGPZhHaYfLsMkiQcR"

JUNE 25, 2014:
1SomeBTCAddressT56mDQzEdebQdibmigU-> 1ANGELwQwWxMmbdaSWhWLqBEtPTkWb8uDc | AMOUNT: 1 BTC


Now this person gets to control his 2BTC worth of BTS X with his new address 1AnotherBTCAddressGPZhHaYfLsMkiQcR, even though transfer happened after the snapshot, it happened before BTSX went live. As well as 5 BTC of all future DACs honoring AGS. The 1BTC on JUNE 25, will still be controlled by original address since donation occurred after the transfer.

Or if BM thinks this seems too complicated, then we can just do it for future releases.
Title: Re: AGS potential security issue
Post by: xeroc on June 02, 2014, 06:39:35 am
Sending messages over bitcoin network is not possible.
Blockchain.info is just a centralized service that one can use to send a message. or are you proposing the use of OP_RETURN?
Title: Re: AGS potential security issue
Post by: bitmeat on June 02, 2014, 06:50:59 am
I missed that detail, but my solution still works. Let me provide more info.

Make a special 1_AGS_TRANSFER BTC address.

When you want to send a "TRANSFER TO xxx" message as a transaction do this:

Send 0.01 BTC (or whatever fee BM thinks is appropriate, or if generous make it 1 satoshi) to the 1_AGS_TRANSFER address.
In the same transaction send 1 satoshi to the new BTC address that will control your AGS

So you have

INPUT:
OLD_DONOR_ADDRES

OUTPUTS:
1_AGS_TRANSFER | AMT: FEE (say 0.01BTC)
1_NEW_DONOR_ADDRESS | AMT: 1 satoshi

This is totally doable. Parser generating genesis addresses would need to be adjusted to look for 1_AGS_TRANSFER as well.
Title: Re: AGS potential security issue
Post by: bitmeat on June 02, 2014, 06:54:39 am
I think BM could even do this for 1% fee of all transfers using this method. That way it is discouraged.

Or if he is feeling generous he could have all transfer fees be redistributed to the rest of the group. That way those who stick around get an even higher dividend.
Title: Re: AGS potential security issue
Post by: xeroc on June 02, 2014, 06:59:06 am
I missed that detail, but my solution still works. Let me provide more info.

Make a special 1_AGS_TRANSFER BTC address.

When you want to send a "TRANSFER TO xxx" message as a transaction do this:

Send 0.01 BTC (or whatever fee BM thinks is appropriate, or if generous make it 1 satoshi) to the 1_AGS_TRANSFER address.
In the same transaction send 1 satoshi to the new BTC address that will control your AGS

So you have

INPUT:
OLD_DONOR_ADDRES

OUTPUTS:
1_AGS_TRANSFER | AMT: FEE (say 0.01BTC)
1_NEW_DONOR_ADDRESS | AMT: 1 satoshi

This is totally doable. Parser generating genesis addresses would need to be adjusted to look for 1_AGS_TRANSFER as well.
Much like satoshi dice ...

Can work .. however. To generate a new genesis block for new DACs you now need to pars 2 addresses .. that is an overhead.

But still, nice solution!
Title: Re: AGS potential security issue
Post by: bitmeat on June 02, 2014, 07:00:52 am
We already have a tool that parses one address, that's the hard work and it's been done. Parsing a second one is trivial.

EDIT: I might have misunderstood. Did you mean we can't parse multiple output transactions? :)
Title: Re: AGS potential security issue
Post by: xeroc on June 02, 2014, 07:18:03 am
We already have a tool that parses one address, that's the hard word and it's been done. Parsing a second one is trivial.
True.
Quote
EDIT: I might have misunderstood. Did you mean we can't parse multiple output transactions? :)
Why should we not. Sure we can. Having multiple inputs might be an issue, but sending 1 satoshi can be done with one input easily :-)
Title: Re: AGS potential security issue
Post by: bitmeat on June 02, 2014, 07:19:04 am
Then what overhead are you talking about? :)
Title: Re: AGS potential security issue
Post by: bitmeat on June 02, 2014, 07:26:16 am
Or even simpler:

Scratch the Fees idea (originally I was looking for a design that would motivate Invictus to do this)

INPUT:
OLD_DONOR_ADDRES

OUTPUTS:
1_ANGEL_ADDRESS | AMT: 1 satoshi
1_NEW_DONOR_ADDRESS | AMT: 1 satoshi


If sent 1 satoshi to ANGEL address combined with 1 satoshi to another address, then that's the transfer of responsibility.

DONE - won't even need to create/parse new vanity address! :)
Title: Re: AGS potential security issue
Post by: blahblah7up on June 03, 2014, 05:12:11 pm
I raised this question several months ago and still think it is very important to find a solution.

https://bitsharestalk.org/index.php?topic=3422.msg42965#msg42965

The idea about using a signed message to avoid exposing the private key doesn't solve the issue because of the ever present possibility of ERRANT HUMAN BEHAVIOR.  Once the keys are "accidentally" exposed, it should be possible to somehow correct the situation (like in any email program you can log in and change your password if for whatever reason you feel that you should).

Suppose for instance someone breaks into your house and you have your private keys stored somewhere.  Nothing is missing and you don't know if the keys were even discovered but you would just feel safer to change those private keys.  At the moment this isn't an option.
Title: Re: AGS potential security issue
Post by: bitmeat on June 03, 2014, 05:25:41 pm
I disagree. Signing a message transfers over the responsibility to a new unexposed private key. How does that not solve the problem?
Title: Re: AGS potential security issue
Post by: blahblah7up on June 03, 2014, 06:31:28 pm
As I understood the suggestion, the signed message was to be used to collect the shares of the new DAC instead of the private key.  But if the private key has already been exposed anyone who has it can create that signed message.
Title: Re: AGS potential security issue
Post by: blahblah7up on June 03, 2014, 06:38:47 pm
That is how I interpreted CrazyBit's suggestion.

You seem to be suggesting that AGS will be liquid but I still haven't heard anything that suggests that from anyone within Invictus.
Title: Re: AGS potential security issue
Post by: bitmeat on June 03, 2014, 06:56:40 pm

That is how I interpreted CrazyBit's suggestion.

You seem to be suggesting that AGS will be liquid but I still haven't heard anything that suggests that from anyone within Invictus.

Yes, my proposal makes it liquid and is extremely easy to implement. Had I seen some support from Invictus I would even volunteer to implement it. But no dice. So we wait. Seems like we are close for the BTS X though.

Title: Re: AGS potential security issue
Post by: bitmeat on June 03, 2014, 07:06:16 pm

As I understood the suggestion, the signed message was to be used to collect the shares of the new DAC instead of the private key.  But if the private key has already been exposed anyone who has it can create that signed message.

As far as private key already exposed there is no good way to solve that with the current system. I did like the idea of using derived individual private key per DAC so that if one DAC software steals it, it doesn't compromise the rest of your apps.
Title: Re: AGS potential security issue
Post by: toast on June 03, 2014, 08:10:33 pm

That is how I interpreted CrazyBit's suggestion.

You seem to be suggesting that AGS will be liquid but I still haven't heard anything that suggests that from anyone within Invictus.

Yes, my proposal makes it liquid and is extremely easy to implement. Had I seen some support from Invictus I would even volunteer to implement it. But no dice. So we wait. Seems like we are close for the BTS X though.

I think it's a pretty good idea, and anyone is free to implement it. Likewise anyone is free to just go ahead and implement a liquid version of AGS once the donation period ends.

I just don't think anyone here wants to change the officially endorsed definition of AGS, don't want to make the "changing the deal" reputation worse.
Title: Re: AGS potential security issue
Post by: bitmeat on June 03, 2014, 09:15:00 pm


That is how I interpreted CrazyBit's suggestion.

You seem to be suggesting that AGS will be liquid but I still haven't heard anything that suggests that from anyone within Invictus.

Yes, my proposal makes it liquid and is extremely easy to implement. Had I seen some support from Invictus I would even volunteer to implement it. But no dice. So we wait. Seems like we are close for the BTS X though.

I think it's a pretty good idea, and anyone is free to implement it. Likewise anyone is free to just go ahead and implement a liquid version of AGS once the donation period ends.

I just don't think anyone here wants to change the officially endorsed definition of AGS, don't want to make the "changing the deal" reputation worse.

Right, but we wouldn't be changing the distribution amounts, just allowing ownership to be transferred, prior to launch. Anyways. We live and learn. I would do this if I know Invictus would honor it for BTSX otherwise I have no incentive at the moment.
And again, it seems they are much closer to release so defeats the purpose a bit. But had the idea met less criticism I could've had it up and running back in March.

Thanks for the positive feedback, toast!
Title: Re: AGS potential security issue
Post by: blahblah7up on June 03, 2014, 10:01:36 pm

As I understood the suggestion, the signed message was to be used to collect the shares of the new DAC instead of the private key.  But if the private key has already been exposed anyone who has it can create that signed message.

As far as private key already exposed there is no good way to solve that with the current system. I did like the idea of using derived individual private key per DAC so that if one DAC software steals it, it doesn't compromise the rest of your apps.

I also like this idea but it still relies on a single point of failure.  In that case you better be sure you made your AGS donation with a signed tx from a paper wallet created on an air gapped computer.

Do you think most people did?
Title: Re: AGS potential security issue
Post by: bytemaster on June 04, 2014, 02:03:48 am
Making AGS liquid will have to be a community activity and is not something we can do.  If AGS were tradable it would become property and this property could become a security with imaginative regulators.  While AGS is not tradable it is not property nor an asset.  It is merely a record of your donation that other DAC launchers may airdrop to. 

If someone wants to come along and create Liquid AGS and then market it as the better choice to airdop to then that is their business, but we cannot endorse it or 'bless it'.     
Title: Re: AGS potential security issue
Post by: Stan on June 04, 2014, 02:23:05 am
Making AGS liquid will have to be a community activity and is not something we can do.  If AGS were tradable it would become property and this property could become a security with imaginative regulators.  While AGS is not tradable it is not property nor an asset.  It is merely a record of your donation that other DAC launchers may airdrop to. 

If someone wants to come along and create Liquid AGS and then market it as the better choice to airdop to then that is their business, but we cannot endorse it or 'bless it'.     

+1

Precisely.  Plus, you don't want us to:

1.  Its unique property is that it lets developers air-drop to proven donors - an awesome demographic.
2.  If you make it tradable, then it is no different from PTS.
3.  So a third party might ask, "Why is this one demographic worth 20%?"

You want PTS and AGS to stay separate demographics, each worth honoring for its own reason.
Title: Re: AGS potential security issue
Post by: sfinder on June 04, 2014, 02:53:35 am
Making AGS liquid will have to be a community activity and is not something we can do.  If AGS were tradable it would become property and this property could become a security with imaginative regulators.  While AGS is not tradable it is not property nor an asset.  It is merely a record of your donation that other DAC launchers may airdrop to. 

If someone wants to come along and create Liquid AGS and then market it as the better choice to airdop to then that is their business, but we cannot endorse it or 'bless it'.     

+1

Precisely.  Plus, you don't want us to:

1.  Its unique property is that it lets developers air-drop to proven donors - an awesome demographic.
2.  If you make it tradable, then it is no different from PTS.
3.  So a third party might ask, "Why is this one demographic worth 20%?"

You want PTS and AGS to stay separate demographics, each worth honoring for its own reason.

how can we protect our AGS private key while claiming shares from  3rd party DAC?
Title: Re: AGS potential security issue
Post by: Stan on June 04, 2014, 02:55:57 am
Making AGS liquid will have to be a community activity and is not something we can do.  If AGS were tradable it would become property and this property could become a security with imaginative regulators.  While AGS is not tradable it is not property nor an asset.  It is merely a record of your donation that other DAC launchers may airdrop to. 

If someone wants to come along and create Liquid AGS and then market it as the better choice to airdop to then that is their business, but we cannot endorse it or 'bless it'.     

+1

Precisely.  Plus, you don't want us to:

1.  Its unique property is that it lets developers air-drop to proven donors - an awesome demographic.
2.  If you make it tradable, then it is no different from PTS.
3.  So a third party might ask, "Why is this one demographic worth 20%?"

You want PTS and AGS to stay separate demographics, each worth honoring for its own reason.

how can we protect our AGS private key while claiming shares from  3rd party DAC?

Aye.  There's the right question to be discussing.
Title: Re: AGS potential security issue
Post by: sudo on June 04, 2014, 03:02:20 am
how about give a chance to  transfer AGS  such as  every other year?
Title: Re: AGS potential security issue
Post by: bitmeat on June 04, 2014, 04:03:03 am
So help me understand - PTS doesn't have regulatory issues because it was mined, not issued? And in retrospect - AGS might have regulatory issues, because it was directly funded?

I'm asking because from a technical perspective I don't see any issues implementing this. It seems that you guys are avoiding it like a hot potato, but if that's what your lawyers said then I guess it explains the resistance on your part.
Title: Re: AGS potential security issue
Post by: Stan on June 04, 2014, 04:10:41 am
So help me understand - PTS doesn't have regulatory issues because it was mined, not issued? And in retrospect - AGS might have regulatory issues, because it was directly funded?

I'm asking because from a technical perspective I don't see any issues implementing this. It seems that you guys are avoiding it like a hot potato, but if that's what your lawyers said then I guess it explains the resistance on your part.

Don't get us wrong.  As serious AGS holders we would benefit from having them be liquid.  But we stated multiple reasons, among which are regulatory considerations.

Watch for Parts 2 and 3 of "Happy Birthday BitShares."  You'll get more insights there.

In the mean time, I'll point out that, as a ProtoDAC, XTS will make AGS partly liquid, since all BitShares X variants will be derived from it.  Over time, other ProtoDAC families will do the same.  See our March Newsletter for detail on the concept of ProtoDAC families and DAC industry sectors.

Title: Re: AGS potential security issue
Post by: xeroc on June 04, 2014, 06:30:09 am
how can we protect our AGS private key while claiming shares from  3rd party DAC?

Aye.  There's the right question to be discussing.

We already do (obviously unnoticed):
https://bitsharestalk.org/index.php?topic=4737.msg61330#msg61330

Could you (@Stan or @Bytemaster) comment on Freetrades idea?
Title: Re: AGS potential security issue
Post by: toast on June 04, 2014, 04:03:08 pm
I feel like I've read that suggestion like 4 times already.

Yes, having a tool to sign the transaction outside the 3rd party DAC is a good idea. I think nobody is discussing it because it seems obvious...
Title: Re: AGS potential security issue
Post by: xeroc on June 04, 2014, 04:29:07 pm
I feel like I've read that suggestion like 4 times already.

Yes, having a tool to sign the transaction outside the 3rd party DAC is a good idea. I think nobody is discussing it because it seems obvious...
+5%
Title: Re: AGS potential security issue
Post by: testz on June 06, 2014, 10:02:59 pm
I feel like I've read that suggestion like 4 times already.

Yes, having a tool to sign the transaction outside the 3rd party DAC is a good idea. I think nobody is discussing it because it seems obvious...

Look like new etherum use same idea  :)
https://bitcointalk.org/index.php?topic=563925.0

Quote
13.  But I don’t trust you with my bitcoin private keys.

There is no need to trust us.  Simply sign an æther address under your control with a bitcoin private key using whatever wallet you are comfortable with (e.g., blockchain.info, Armory, etc.,) and paste the resulting signature into the æthereum client.