Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FIP proposal: A more secure signature method of worker&post account #112

Closed
arsadmin opened this issue Jun 8, 2021 · 5 comments
Closed

Comments

@arsadmin
Copy link

arsadmin commented Jun 8, 2021

Simple Summary

In Filecoin network,miners use worker and PoSt account to signature the messages. And the private keys of worker and post wallet have to be stored on the Lotus-miner server or other signature server for a long time. Once the server was attacked by hackers and the private key was stolen, The miner will suffer great loss of asserts.

Change Motivation

We proposal a different signature method of worker wallet and post wallet by classifying the messages to protect the miner’s asserts.

Specification

In filecoin , there are two main work accounts: worker account and post account.

Worker account: miners use it to submit the PreCommitSector and ProveCommitSector messages when sealing the sectors. During these processes, miners need to provide the pledge of sectors and pay gas fee.(part of gas fee will be payed to the miner which packed the messages and the rest will be burned by transferring to f099). Usually, these transactions are a kind of contract transfer.

Post account: miners use it to submit the SubWindowedPoSt messages. During these processes, During these processes, miners also need to pay gas fee.(part of gas fee will be payed to the miner which packed the messages and the rest will be burned by transferring to f099). Usually, these transactions are a kind of non-contract transfer.

So we can classify the transfer messages as follows.

  • Working transfer : the transaction behavior of miner in the process of sealing the sectors, submitting the Posts and so on. Including providing the pledge of sectors, paying the gas fee.

  • Financial transfer : the transactions that are not working transfer. Such as miner A transacts to miner B, miner A transacts to individual account, miner A transacts to f099.

Therefore, we can make a definition by smart contract that if Worker account and Post account are doing some working transferring, which are contract transfer, they just adopt the Single signature. However, if they are doing some financial transferring, which are non-contract transfer, they are suggested to adopt the Multi signature.

By this way, we can effectively protect the miner’s asserts from loss when the private key of worker/post account was stolen.

@Stebalien
Copy link
Member

I understand approximately what you're looking for, but the details of this proposal are hard to understand.

There are three types of keys:

  1. Worker key: used to mint blocks.
  2. Owner key: used to manage control of the miner and extract funds.
  3. Control keys: used to manage sectors, submit proofs, etc.

Once the server was attacked by hackers and the private key was stolen, The miner will suffer great loss of asserts.

I assume you mean "assets"? Only the owner key can be used to withdraw funds, and the owner key does not need to be on any server.

However, the control and worker keys can be used to, e.g., terminate sectors, etc (which could lead to fund loss, but wouldn't gain the attacker anything).

I agree more granular permissions would be very helpful here, but this will need a more detailed and accurate proposal.

@arsadmin
Copy link
Author

arsadmin commented Jun 9, 2021

@Stebalien Thank you for your reply. As you mentioned I update that what I really want to say is the control key that can be more secure.

In our practical mining, usually we have two control keys. One is used to provide the gas fee when Sealing the sectors (messages linke PreCommitSector and ProveCommitSector), we usually call it gas address. The other one is used to provide the gas fee when doing the PoSt (messages like SubWindowedPoSt), we usually call it PoSt address.

So these two control keys need to have enough FILs to provide the gas fee. Once the miner was attacked by hackers and the control keys were stolen, The miner will suffer great loss of asserts.

So as mentioned above, when the control account send FILs during PreCommitSecotor\ProveCommitSector\SubWindowedPoSt and so on, just Single signature like now, it's OK. we can call these working transfer.

But if the control account want to send FILs directly to someone else with no working messages(like PreCommit\ProveCommitSector\SubWindowedPoSt). These kind of transferring(we can call them Finanical transfer) need to use Multi signature. So even the control keys were stolen, they can't get the FILs in the account.

if there is any doubt, please feel free to let me know.

@Stebalien
Copy link
Member

I think I'm getting your point now. The short version is: you want special "limited" accounts that can only:

  1. Pay for gas (cannot pay send funds).
  2. Ideally only sends specific kinds of messages to specific addresses.

This is doable in theory but would require adding some potentially complex logic to the filecoin message validation step. This can't be implemented as a simple smart contract.

This would reduce the incentive for stealing these keys. But do note that:

  1. A key used for window posts can still be used to cost the miner funds by submitting invalid window posts (which can later be disputed).
  2. A key used for pre-commits can be used to make known-bad pre-commits, costing the pre-commit deposit.
  3. A malicious miner could pay themselves a high premium using these keys.
  4. An attacker could simply burn all the gas in these keys.

@steven004
Copy link
Contributor

Could you think about a remote wallet for signature? e.g. Venus-wallet, which has advanced security features. You could configure different policy for different keys, and of course, the keystore is encrypted. It may solve all your problem, but I would think it will mitigate most.

@kaitlin-beegle
Copy link
Collaborator

Closing this issue, due to lack of activity.

I am also not sure that this proposal, if pursued, would make sense as an on-chain protocol change. To Steven's point, this type of security configuration would probably be better pursued as an implementation feature/enhancement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants