[Worker Proposal] OpenLedger User Security Worker Proposal

[fav]

I'd actually vote for a worker to integrate and maintain scatter functionality, that would add some awesome synergies in my opinion.

other than that I agree with sschiessl, key changes etc should be handled by core worker. perhaps your devs could liaise with @fox and you get paid from that worker

[sschiessl]

Dear OpenLedger Team,

thank you for the initiative! I read it and would like to comment on it. To your summary:

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.

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.

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?

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?

To Active vs Owner key:

- 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.

- 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.

In general: Will everything be available as open source and/or implemented directly in the BitShares UI?

Best regards,
 Stefan

[ccedk_pro]

Executive summary

After a recent phishing attack, the OpenLedger team has gone through a series of massive brainstorm sessions, aiming to come up with a solution, which makes further attacks impossible, much harder  or at least, that minimizes the impact of a potential attack. It has became obvious that these types of attacks will continue as more and more new businesses join the BitShares ecosystem and new faucets are launched. User security becomes a paramount focus for the community. Below is a list of the changes we would like to introduce to allow BitShares users to protect themselves and mitigate the risk and impact of phishing attacks or any other attacks that can cause private key loss.

Briefly, we propose the following changes:

• 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).
• 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.
• 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.
• 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.

Given the complexity, importance and potential impact of security for BitShares and for the community, it is difficult to have a complete solution for the features mentioned above without thorough brainstorming, research, analysis and design.

This worker is for funding the Analysis and Architecture phase to elaborate on the features mentioned above, and to describe and estimate specific and feasible security solutions that can be implemented later.

Total duration: 2 months, Aug 6 2018 - Oct 5, 2018.

Total cost: 49 080 bitUSD.

The Solution

Here is how we envisage the changes mentioned above at the high functional level.

Active vs Owner private keys: Separation of Duties

At this time, each account in BitShares is separated into:

• Owner Permission: This permission has administrative powers over the whole account and should be considered for ‘backup’ strategies.
• Active Permission: Allows to access funds and some account settings, but cannot change the owner or Active permission and is thus considered the ‘online’ permissions.

This is a great approach, but if both Owner and Active private keys are stored in the same pocket the user loses both keys if a successful phishing attack was done or the wallet was compromised.

We do believe that Owner and Active private keys must be stored in different wallets, preferably on different devices.

A User uses only the Active key for day-to-day operations, but when they need to manage their account, the Owner key should be used.

Hence, to minimize the impact of a successful phishing attack on a User’s regular account (if a user suspects that Active key is compromised), we suggest to limit the Active key permissions in the following way:

• 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.
• 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).

Each of these settings can be modified only with the Owner private key.

These changes will provide BitShares users with a set of powerful tools, allowing them to configure security settings of the account so that users' assets stay safe even after a successful hacker attack or a security breach.

Device-Tagged Transactions

Security and privacy are key requirements of any BitShares user. However, they often contradict each other. Being anonymous is good, but anonymity is something that gives bad guys more power. If your key has been stolen, the blockchain will accept transactions signed with this key. It does not matter if they were sent by you or by the hacker. You can configure your account so that two or more signatures are required for each transaction, but if you are an active trader and submit hundreds of transactions daily, this is not a realistic option. To help active traders to keep their funds safe we suggest implementing a new transaction type - device-tagged transaction.

Let's imagine that a user has a trading BitShares account with two Active keys. If a user submits a signed device-tagged transaction, then a witness node adds DeviceID to the transaction and records it in the blockchain. DeviceID is a hash of particular data that belongs to a particular device (e.g. hash of IP address, MAC or any other device-specific information). The key requirement here is that the DeviceID is unique for each device, but the device cannot be uncovered by this ID to protect privacy of the user. Now that the user has sent their device-tagged transaction to the blockchain, they can confirm this transaction on another device.  Moreover, once a user recognizes transaction or device, they can enable auto-sign, so that future transactions from this device are automatically signed and fulfilled.

This gives the user the ability to filter out any transactions coming from an unauthorized device, even if one of the Active private keys has been stolen. It’s a method that  allows a two-factor  authorization approach even if hundreds or thousands transactions are submitted by the account daily.

User-Friendly Accounts and Keys Management

As a typical non-technical BitShares user, you need a web, mobile or desktop application to interact with the blockchain. And the problem is that you have to trust the application provider. Besides, the current new user registration and account management approach is extremely non-user-friendly. This leads to users leaving BitShares for other exchanges.

We  suggest that a new open source application should be implemented, allowing users to:

• View and manage their wallets, accounts and private key in a very transparent and user-friendly manner: e.g. view wallets stored on this device, accounts and private keys in the wallets, their relationships and interdependence (e.g. accounts hierarchy or multi-signature accounts), generate and replace private keys, and set limits for Active keys.
• Sign or auto-sign transactions, with the ability to see and filter Device ID, if a device-tagged transaction has been generated.
• Notify users by listening to the blockchain, searching for specific transaction types (e.g. transactions signed by specific key) and sending out emails and displaying notifications.

The applications can be created as a browser plugin, desktop and mobile app, and users can use a particular application type depending on their needs and habits.

To register and trade, users will still need to use a proprietary or BitShares standard application, but they now will have the ability to use a trusted open source locally executed application to configure their account security and manage keys.

Even if a user registered and traded on a phishing site, they can still protect their funds  by replacing private keys or configuring multi-signature account in a separate trusted application. We hope that dealing with private keys in a stand-alone open-source application only will become a standard way for most users.

The Worker Proposal

Worker Scope

OpenLedger believes in a transparent and steady, step-by step development approach. Before we jump into major implementation project, we would like to perform detailed technical investigation, which will deliver clear and straightforward specifications and estimation of the new features and components to be implemented.  This worker is to fund this Analysis and Architecture phase only. As soon as the investigation for a particular feature is completed and specifications along with estimations are delivered to the community, new implementation workers will be submitted for public approval.

Work Approach and Costs

Immediately upon the approval of the worker, OpenLedger will allocate the resources listed below to perform the investigation and provide the deliverables. Reports outlining time spent and current progress to be published on bi-weekly basis. At this point, we estimate the Analysis and Research to take 2 months. Below is the resources and costs breakdown.

Worker daily pay: 3 885 BTS

Payment

We strongly believe in a bright future for BitShares, and this worker will make a great contribution to that. Therefore, we would like to be paid in BTS, BitShares core asset. Accepting BTS instead of bitUSD also allows us to not over-utilize daily workers budget by claiming more BTS than is needed to cover the current costs, leaving room for more workers to be executed simultaneously. In order to avoid over- and under-payment, we will settle the payment at the end of the worker using the current price of BTS in bitUSD. If, due to BTS rate fluctuations, more funds will be needed to complete the job, an additional worker will be created. If we need less effort or BTS rate increases, unspent BTS will be sent back to the reserve pool.

All payments will be vested for 1 month.

Openness for suggestions

Security is a complex but vital topic for BitShares and for blockchain technology. There has to be a way between tightening up security and staying anonymous, while keeping everything decentralized. 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.