Author Topic: [Worker Proposal] OpenLedger User Security Worker Proposal  (Read 12076 times)

0 Members and 1 Guest are viewing this topic.

Offline clockwork

  • Committee member
  • Sr. Member
  • *
  • Posts: 376
    • View Profile
  • BitShares: clockwork
As a witness I would like to suggest add a "Witness Key" to update signing key and publish price feed only.

Please see : https://github.com/bitshares/bitshares-core/issues/1061

Stefan's concept there is a generic solution to exactly that problem.

Offline Bangzi

  • Sr. Member
  • ****
  • Posts: 321
    • View Profile
    • Steemit: Bangzi
  • BitShares: bangzi
As a witness I would like to suggest add a "Witness Key" to update signing key and publish price feed only.

Thanks for your input, Bangzi. Could you please elaborate more, what is the purpose and the logic behind it?

Now witnesses use Private Key to update signing key and publish price feed. The Private Key stored in server and if the server compromised, hackers able to transfer the fund.
Bitshares DEX - Over 1000 Coins, Buy, Sell, Transfer & List Any Coins |Free Signup Today: https://wallet.bitshares.org/?r=bangzi

Offline yury

  • Jr. Member
  • **
  • Posts: 42
    • View Profile
    • openledger.info
As a witness I would like to suggest add a "Witness Key" to update signing key and publish price feed only.

Thanks for your input, Bangzi. Could you please elaborate more, what is the purpose and the logic behind it?
Yury Cherniawsky
OpenLedger

Offline Bangzi

  • Sr. Member
  • ****
  • Posts: 321
    • View Profile
    • Steemit: Bangzi
  • BitShares: bangzi
As a witness I would like to suggest add a "Witness Key" to update signing key and publish price feed only.
Bitshares DEX - Over 1000 Coins, Buy, Sell, Transfer & List Any Coins |Free Signup Today: https://wallet.bitshares.org/?r=bangzi

Offline yury

  • Jr. Member
  • **
  • Posts: 42
    • View Profile
    • openledger.info

Some implementation concerns/details:

1. the user account is a multi-sig account, e.g. 2/4, one key in a hot wallet, one key in cold storage, one key controlled by a trusted 3rd party, one key on a special device;
2. every time when creating a transaction with the hot wallet, it adds a special ID hash into it, for example, set it into a custom operation. In this process, a proposal can be used;
3. The ID hash should be different for every transaction (a one-time key). For example, the user have a secret phrase only known by himself or probably shares with the trusted 3rd party, can be "mysecret123", when crafting the transaction (with the hot wallet), the wallet generates a random number, hash the phase plus the random number, put the random number and the hash in a custom operation;
4. the 3rd party or the special device knows the phase, so can check whether the transaction is proposed by the real user, then add one more signature automatically or not.

Actually this approach doesn't need to change anything in core, but all can be done in UI. The hard thing is how to make it noob friendly.

Thank you very much for your input, Abit!
The original idea was not to sign every transaction, because this won't work for traders. Once a device is "authorized", all further transactions coming from it are auto signed. The exact "device tagging" mechanizm may vary and your approach may also be implemented. Still, we believe it is not client app to tag the transaction, because it may be compromised. It shall be done on a node IMO. Anyhow, this is what investigation phase is for - assess different options and select the best one.
 
Yury Cherniawsky
OpenLedger

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
Thanks a lot Milos for your feedback!
Please see my comments below.

Dear Stefan, it seems we are very close in terms of the security approach and specific features implementation. We launched the worker as it is, but also would like to get in touch with BBF to find the best ways to deliver. If needed, we will create another worker to implement the approach that works best for all parties.

I would be supporting any contribution to a Core Team Worker with funds designed for integrations/developments as these are, and I would be giving my vote to the new worker when all steps mentioned are done and confirmed by all parties.
Awesome! We will do our best to be integrated into Core Team Worker.


The idea is to make a node to generate the device id and store it along with the transaction, so a client has nothing to do with that. 
Ok, so that would basically be some kind of hashing of user given values (e.g. MAC adress or IP, some kind of hardware hash etc.). Sending that information to the node (server) brings aspects of user identification and anonymity in play. Question in my head: Is there a way to tighten security without compromising identity?

I would not be supportive towards centralized server that will host all of that private information from a user/client when we don't even have basic KYC form. It's creating another security risk plus illegally compromising privacy information of individual without previous signed agreement to it. E.g. "Terms of Use" thick box with defined legal obligations and limits of the service, clearly stating which information is being obtained, how is being stored and what would happen if it gets compromised. Everything would be in a need to be legally defined, and each user has agreed to it during registration of his account, which still brings us back how we would process all accounts already created without it and as mentioned how it would affect all that anonymity hype with account creation we currently present ?

Thanks in advance for feedback and will be following up on communication progress and new worker.

Cheers
It seems to me that in the worker text we were not specific enough and this causes some misunderstanding. Let me try to provide more detailed workflow, I do hope this will make the idea more clear.
1. A User has an account with 2 Active keys.
2. He submits a "device tagged" transaction to a node, signed with 1st Active key.
3. The node takes user's device ID (e.g. hashed IP) and stores along with transaction. There is no way to guess IP knowing the hash, so we don't store any private information.
4. On another device (e.g. mobile) the user sees that a transaction with specific ID has been submitted. He know he has submitted this transaction on another device, so the ID attached to the transaction must be "safe". Now he can auto approve all transactions having this ID.

With this approach we do not store any private info and do not violate user's anonymity, we just allow him to identify which transactions were created by him from another device, by tagging them with unique device ID.

Some implementation concerns/details:

1. the user account is a multi-sig account, e.g. 2/4, one key in a hot wallet, one key in cold storage, one key controlled by a trusted 3rd party, one key on a special device;
2. every time when creating a transaction with the hot wallet, it adds a special ID hash into it, for example, set it into a custom operation. In this process, a proposal can be used;
3. The ID hash should be different for every transaction (a one-time key). For example, the user have a secret phrase only known by himself or probably shares with the trusted 3rd party, can be "mysecret123", when crafting the transaction (with the hot wallet), the wallet generates a random number, hash the phase plus the random number, put the random number and the hash in a custom operation;
4. the 3rd party or the special device knows the phase, so can check whether the transaction is proposed by the real user, then add one more signature automatically or not.

Actually this approach doesn't need to change anything in core, but all can be done in UI. The hard thing is how to make it noob friendly.
BitShares committee member: abit
BitShares witness: in.abit

Offline yury

  • Jr. Member
  • **
  • Posts: 42
    • View Profile
    • openledger.info
Thanks a lot for your feedback, Fabian!

I, too, support efforts to bring more security to the blockchain.
The costs for 50k$ for specifications and research is somewhat difficult to understand given that
many community contributors already have a list of features that overlap 80% with your desires.
At this time I am only aware of proposal from Stefan about custom active permissions, and still it needs more technical investigation. Could you please advise, what other features you have on your mind?

I would like to kindly request that the Openledger development team gets in contact with the
bitshares-core development to discuss which specs already exist or are near completion, rather
than duplicate efforts.
Sure, this is what we are going to do.

Quote
Further, I have made contact with the developer of Scatter already and he would love to help
integrate BitShares into Scatter after his refactoring. So, I would rather get things started with
the existing foundations of scatter than re-invent the wheel.
It may be the good option, but there are some concerns as well.
I had a closer look at Scatter and here is this app is compared to our proposal IMO:
- Scatter is one wallet per device for many keys for many blockchains, while our app shall be able to handle many wallets for one blockchain, each protected with a separate password.
- Scatter is not able to show accounts and keys relationships (e.g. multisigs, accounts hierarchy, etc).
- Scatter can't generate new Bitshares keys for you.
- Scatter does not have auto sign functionality.
- Scatter does not have blockchain listener and notifications mechanizm
And finally, Scatter is an independent app. Today it is opensource, but we have no idea if it will be opensource in a year. We also have to rely on the app owner and align to his app roadmap. Being integrated into Scatter is nice, but we believe we shall also have a separate Bitshares dedicated open source app. 

Quote
Last but not least, I would like to iterate over the existance of a Proof-Of-Concept implementation
for Steem/Graphene for the original Trezor. Specs are more or less complete and we could go into
implementations any time there is funding and human resources that support development.
Nice option, but same concerns as for Scatter.

Quote
Finally, I much enjoyed reading this proposal. OpenLedger established itself long ago as a solid pillar
in the BitShares ecosystem. Glad to see your desire to give back to the community.

Thanks a lot, Fabian! Your opinion is extremely important and your contribution to Bitshares can't be overestimated.
Yury Cherniawsky
OpenLedger

Offline yury

  • Jr. Member
  • **
  • Posts: 42
    • View Profile
    • openledger.info
Thanks a lot Milos for your feedback!
Please see my comments below.

Dear Stefan, it seems we are very close in terms of the security approach and specific features implementation. We launched the worker as it is, but also would like to get in touch with BBF to find the best ways to deliver. If needed, we will create another worker to implement the approach that works best for all parties.

I would be supporting any contribution to a Core Team Worker with funds designed for integrations/developments as these are, and I would be giving my vote to the new worker when all steps mentioned are done and confirmed by all parties.
Awesome! We will do our best to be integrated into Core Team Worker.


The idea is to make a node to generate the device id and store it along with the transaction, so a client has nothing to do with that. 
Ok, so that would basically be some kind of hashing of user given values (e.g. MAC adress or IP, some kind of hardware hash etc.). Sending that information to the node (server) brings aspects of user identification and anonymity in play. Question in my head: Is there a way to tighten security without compromising identity?

I would not be supportive towards centralized server that will host all of that private information from a user/client when we don't even have basic KYC form. It's creating another security risk plus illegally compromising privacy information of individual without previous signed agreement to it. E.g. "Terms of Use" thick box with defined legal obligations and limits of the service, clearly stating which information is being obtained, how is being stored and what would happen if it gets compromised. Everything would be in a need to be legally defined, and each user has agreed to it during registration of his account, which still brings us back how we would process all accounts already created without it and as mentioned how it would affect all that anonymity hype with account creation we currently present ?

Thanks in advance for feedback and will be following up on communication progress and new worker.

Cheers
It seems to me that in the worker text we were not specific enough and this causes some misunderstanding. Let me try to provide more detailed workflow, I do hope this will make the idea more clear.
1. A User has an account with 2 Active keys.
2. He submits a "device tagged" transaction to a node, signed with 1st Active key.
3. The node takes user's device ID (e.g. hashed IP) and stores along with transaction. There is no way to guess IP knowing the hash, so we don't store any private information.
4. On another device (e.g. mobile) the user sees that a transaction with specific ID has been submitted. He know he has submitted this transaction on another device, so the ID attached to the transaction must be "safe". Now he can auto approve all transactions having this ID.

With this approach we do not store any private info and do not violate user's anonymity, we just allow him to identify which transactions were created by him from another device, by tagging them with unique device ID.
Yury Cherniawsky
OpenLedger

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
I, too, support efforts to bring more security to the blockchain.
The costs for 50k$ for specifications and research is somewhat difficult to understand given that
many community contributors already have a list of features that overlap 80% with your desires.

I would like to kindly request that the Openledger development team gets in contact with the
bitshares-core development to discuss which specs already exist or are near completion, rather
than duplicate efforts.

Further, I have made contact with the developer of Scatter already and he would love to help
integrate BitShares into Scatter after his refactoring. So, I would rather get things started with
the existing foundations of scatter than re-invent the wheel.

Last but not least, I would like to iterate over the existance of a Proof-Of-Concept implementation
for Steem/Graphene for the original Trezor. Specs are more or less complete and we could go into
implementations any time there is funding and human resources that support development.

Finally, I much enjoyed reading this proposal. OpenLedger established itself long ago as a solid pillar
in the BitShares ecosystem. Glad to see your desire to give back to the community.

Offline Digital Lucifer

  • Sr. Member
  • ****
  • Posts: 368
  • BitShares Maximalist & Venture Architect
    • View Profile
    • BitShares
  • BitShares: dls.cipher
  • GitHub: dls-cipher
Dear Stefan, it seems we are very close in terms of the security approach and specific features implementation. We launched the worker as it is, but also would like to get in touch with BBF to find the best ways to deliver. If needed, we will create another worker to implement the approach that works best for all parties.

I would be supporting any contribution to a Core Team Worker with funds designed for integrations/developments as these are, and I would be giving my vote to the new worker when all steps mentioned are done and confirmed by all parties.


The idea is to make a node to generate the device id and store it along with the transaction, so a client has nothing to do with that. 
Ok, so that would basically be some kind of hashing of user given values (e.g. MAC adress or IP, some kind of hardware hash etc.). Sending that information to the node (server) brings aspects of user identification and anonymity in play. Question in my head: Is there a way to tighten security without compromising identity?

I would not be supportive towards centralized server that will host all of that private information from a user/client when we don't even have basic KYC form. It's creating another security risk plus illegally compromising privacy information of individual without previous signed agreement to it. E.g. "Terms of Use" thick box with defined legal obligations and limits of the service, clearly stating which information is being obtained, how is being stored and what would happen if it gets compromised. Everything would be in a need to be legally defined, and each user has agreed to it during registration of his account, which still brings us back how we would process all accounts already created without it and as mentioned how it would affect all that anonymity hype with account creation we currently present ?

Thanks in advance for feedback and will be following up on communication progress and new worker.

Cheers
« Last Edit: July 24, 2018, 10:13:28 am by Digital Lucifer »
Milos (DL) Preocanin
Owner and manager of bitshares.org
Move Institute, Non-profit organization
RN: 2098555000
Murska Sobota, Slovenia.

Offline yury

  • Jr. Member
  • **
  • Posts: 42
    • View Profile
    • openledger.info

I appreciate that you are collecting feedback like mentioned in your initial post. I just noticed that the worker proposal has already been created, leaving no margin for alteration in terms of its approach. I personally would have loved explicit collaboration of the UI and core worker to include OpenLedger into the community development. Disclaimer: I don't carry any significant voting or proxy weight. I am part of the BitShares UI team and managing the infrastructure worker that is done by Blockchain Projects BV.

Dear Stefan, it seems we are very close in terms of the security approach and specific features implementation. We launched the worker as it is, but also would like to get in touch with BBF to find the best ways to deliver. If needed, we will create another worker to implement the approach that works best for all parties.
Yury Cherniawsky
OpenLedger

Offline yury

  • Jr. Member
  • **
  • Posts: 42
    • View Profile
    • openledger.info
Another thing I'd like to add to my comment as a question:

Many things will need to be handled by the core. This worker is for analyzing and architectural planning. That means the proposal will end with a really detailed BSIP for those cases that will then be voted on, correct? Afterwards, if approved, it would be picked up by the core team so a consecutive proposal for that might not be needed.

 I agree with fav, focusing the proposal on the external Scatter like tool and integrating your devs for the parts that touch the core into the core worker might be beneficial, as it would also open up a line of collaboration of OpenLedger and the core team.

Dear Stefan and Fav! Thanks a lot for your opinion on that, collaboration with the core and UI teams may be a good option. I will reach Ryan to find the best way to move forward. Will keep everyone posted! Thanks again!
Yury Cherniawsky
OpenLedger

Offline sschiessl

  • Administrator
  • Hero Member
  • *****
  • Posts: 662
    • View Profile
  • BitShares: sschiessl
Thank you very much for your response! Here are my thoughts

Correct, sophisticated users can configure their private keys and wallets in many ways at the moment, but a regular user typically follows standard flow which is not that safe. The main idea behind our proposal is to make accounts, keys and wallets management easy and user friendly.
Agreed. This can be handled by the UI when signing up, e.g. give the user a checkbox "Enhance account security" which is on per default and would require an active password and an owner password (for both cloud or local wallet login). I bet the BitShares UI team would be happy to welcome you.

Agree, your proposal is very close to our vision. At the first glance your approach seems to be more flexible, while our proposal is more straightforward and easy for user comprehension: it implements user+admin approach. I believe a particular balance to be identified here to make this feature powerful yet easy to use. BTW, what is the status of the BSIP?
I am a firm believer of a flexible approach, while not altering existing behavior. Ease of use can simply be achieved by providing an additional, easy to be found button: "Create trading key" and "Restrict markets" that do the right backend calls. I would not restrict the capabilities of the backend because it allows so many more use cases. The BSIP is in draft stage, I would be happy to collaborate.

The idea is to make a node to generate the device id and store it along with the transaction, so a client has nothing to do with that. 
Ok, so that would basically be some kind of hashing of user given values (e.g. MAC adress or IP, some kind of hardware hash etc.). Sending that information to the node (server) brings aspects of user identification and anonymity in play. Question in my head: Is there a way to tighten security without compromising identity?

Yes, similar to Scatter. Not sure for now if web apps like OL or Bitshares UI shall be required to use the app to sign the transactions, it may be an optional feature for good guys. We discussed several options and decided that you can't make all faucets/gates to use the app, anyhow there will be new phishing apps coming and we shall be protected against them. So the main idea is to deliver opensource trusted app to users to allow them to change their private keys, auto-sign correct "device tagged" transactions and manage Active permissions, so that a hacker has little chance to steal your funds even if he has your Active key.
Totally agreed, it should be optional, but it would be awesome as integration. Signing locally outside of the BitShares UI makes ANY phishing attempt immediately worthless as there is no access to the private key at any point. It would require some rework of the UI to allow to define your active account without giving the private keys. The approach to be preferred IMO is to not even let the phishing party get the key in the first place. Anyways, key management outside in an external open source app would be really great!

Correct, but it is not very easy for a regular user to add/remove keys, also, if you lost the key, you may be in big trouble. Enable/disable the key is much more user friendly and safe.
This is merely a question of a button that does the right operations on the backend. An active key that got compromised, or might be compromised, should never be enabled again, ever. I'm unsure what other use case it has. If the key was lost it's also lost after re-activation.

Quote
We would like to open discussion and we particularly welcome suggestions and ideas about new security features and the best way to design a specific feature
I appreciate that you are collecting feedback like mentioned in your initial post. I just noticed that the worker proposal has already been created, leaving no margin for alteration in terms of its approach. I personally would have loved explicit collaboration of the UI and core worker to include OpenLedger into the community development. Disclaimer: I don't carry any significant voting or proxy weight. I am part of the BitShares UI team and managing the infrastructure worker that is done by Blockchain Projects BV.
« Last Edit: July 24, 2018, 09:09:35 am by sschiessl »

Offline yury

  • Jr. Member
  • **
  • Posts: 42
    • View Profile
    • openledger.info
Dear Stefan!

We do appreciate your feedback! Please find the replies below.



Quote
To minimize risk of both keys being stolen at the same time: Separate Active and Owner private keys, encourage their storage in different wallets (preferably on different devices).
This is a great idea. Already now in the BitShares UI  one could create two local wallets with two different passwords defined on account creation.

Correct, sophisticated users can configure their private keys and wallets in many ways at the moment, but a regular user typically follows standard flow which is not that safe. The main idea behind our proposal is to make accounts, keys and wallets management easy and user friendly.

Quote
Quote
To minimize the impact of Active private key theft: Severely limit permissions for Active private key, while allowing to more fine-grained permissions control with Owner private key.
There is work done currently to formulate a BSIP for this: https://github.com/bitshares/bitshares-core/issues/1061#issuecomment-398017083 , which introduces custom active permissions, which would allow to create a "Trading private key". In combination with you proposed account and markets whitelist it's a great defense. The active key behavior should not be altered imo.

Agree, your proposal is very close to our vision. At the first glance your approach seems to be more flexible, while our proposal is more straightforward and easy for user comprehension: it implements user+admin approach. I believe a particular balance to be identified here to make this feature powerful yet easy to use. BTW, what is the status of the BSIP?


Quote
Quote
To minimize the risk of transactions coming from unknown sources signed with your private key: Introduce new Device-Tagged transaction allowing users to identify and block transactions sent from an unauthorized device and implement multi-signature accounts, essentially moving to 2FA.
This sounds interesting. How do you ensure that an attacker does not mimick the device id that is stored on-chain?
The idea is to make a node to generate the device id and store it along with the transaction, so a client has nothing to do with that. 

Quote
Quote
To make keys and account management more secure and user-friendly: Create simple desktop and mobile applications that allow users to easily manage their accounts and private keys, create multi-signature accounts, sign transactions, enable auto-sign feature, and receive notifications for specific transactions.
This would be gread, similar to Scatter I suppose? Is the idea the following: You are running said new program on the local computer and other application like the BitShares UI can request to get transactions signed?
Yes, similar to Scatter. Not sure for now if web apps like OL or Bitshares UI shall be required to use the app to sign the transactions, it may be an optional feature for good guys. We discussed several options and decided that you can't make all faucets/gates to use the app, anyhow there will be new phishing apps coming and we shall be protected against them. So the main idea is to deliver opensource trusted app to users to allow them to change their private keys, auto-sign correct "device tagged" transactions and manage Active permissions, so that a hacker has little chance to steal your funds even if he has your Active key.


Quote
Quote
- Daily transfer limits can be set for each asset. So that a hacker who steals the Active key is not able to drain the account immediately.
 - Limit the markets where Active key can place orders. So that a hacker can't sell the assets he got illegal access to for their fake assets (Markets whitelist)
 - Specify accounts the user can transfer to. So that a hacker is not able to move funds to their own account (Accounts whitelist).
I like those three. Transfer/Trade volume limit, markets and transfer whitelists. In combination with my above mentioned trade authority only a market (and possibly volume) whitelist would necessary. In the same way the current asset blacklisting functionality could be optimized. For example: The well known binancecleos account could be blacklisted for OPEN.EOS, which *should* have the effect that no one can transfer OPEN.EOS to that account.
Agree!

Quote
Quote
- Owner is able to suspend the account activity. This means that if a user suspects that Active key is compromised, they can suspend the account Active key and then any transaction signed with the compromised Active key will be blocked.
This is already possible simply by removing said active key.
Correct, but it is not very easy for a regular user to add/remove keys, also, if you lost the key, you may be in big trouble. Enable/disable the key is much more user friendly and safe.

Quote
In general: Will everything be available as open source and/or implemented directly in the BitShares UI?
Yes, sure. Generally, we believe that user security is something essential for further development of Bitshares ecosystem. Another successful attack can kill the trust, and unfortunately no faucet can be considered 100% safe. The users must be protected on core level.  Although there are particular protection tools available at the time (e.g. dynamic accounts permissions), and some more improvements were proposed proposed, there should be a consistent solution designed and delivered, this is the goal of this WP.
Yury Cherniawsky
OpenLedger

Offline sschiessl

  • Administrator
  • Hero Member
  • *****
  • Posts: 662
    • View Profile
  • BitShares: sschiessl
Another thing I'd like to add to my comment as a question:

Many things will need to be handled by the core. This worker is for analyzing and architectural planning. That means the proposal will end with a really detailed BSIP for those cases that will then be voted on, correct? Afterwards, if approved, it would be picked up by the core team so a consecutive proposal for that might not be needed.

 I agree with fav, focusing the proposal on the external Scatter like tool and integrating your devs for the parts that touch the core into the core worker might be beneficial, as it would also open up a line of collaboration of OpenLedger and the core team.