Owner key change by random PoSt challenge proposal

[lionsoul2014]

Simple Summary

Data service first - The real owner of a miner should be the one providing the sector data service not the one just own the owner key. Miners can still could get their rewards and all the collateral as long as the data could still provide service even through the owner key lost.

Abstract

For the current FIL network, miners lose their owner key and they lost everything and they have to keep providing service for the data access but without rewards even thought it keeps winning(This is really a terrible story). The FIL network will be more secure and consistent with the original intention of data storage if we provide a mechanism that the owner key could be changed by random PoSt challenge.

Change Motivation

There are some unavoidable situations where we may lose the owner key (and what actually happened):

1. Hacker attach: the lotus server may be hacked cuz of weak network protection (or operation without security awareness) and the owner key was stolen.
2. Hardware errors: Hardware errors like disk corruption before operator backup the owner key or the keystore files.
3. Operating errors: the operator may delete the owner key or the keystore files by mistake without backup.
4. Stolen by operators: we need professional technicians to manage a miner and they may stolen it and control everything by changing the owner key after they quit.

Miners simple can't do anything when they lost their owner key they lost their collateral and all the future rewards. This is a bad investment experience and many participants really care about this "owner key stolen" issue.
Stressing the importance of owner key and admonishing miners to backup their keys is a recurring thing. Miners realizes the importance of the owner key and form a security awareness requires a process and a certain amount of time.

Filecoin is a decentralized storage network and key is to provide data storage and access service so the real miner should be the one keep providing data storage service not the one just own the owner key. What if the network provide a mechanism that allow miners to change their owner key even though they lost it as long as they could provide valid proof for random deadlines or partitions challenge.

That is to say the most important thing to do for a miner is to protect its data and make sure all the data it stored could provide stable service. Miner staking pledged storage space to get rewards and the key is still the storage and storage is a kind of service not a kind of control. So, Will the FIL network be better to make the stable data service as the first thing which means the give the rewards and collateral to the person who provides the data service instead of the person who ONLY owns the owner key ?

Protecting the data is already a hard work, but also we need pay more attension to protect "the most important owner key" that shouldn't be that important. That's really what happened now every day for all the miners. With this implementation the network can give those miners who made this mistake chances to make up for it WITHOUT affecting the reliability of the whole Filecoin network.

Specification

The implementation steps/pseudo is as follows:

1. Register a new bls wallet and active it (named A).

   var nWallet    // a new actived bls wallet generate by cmd 'lotus wallet new bls'
   

2. Submit a owner key change proposal signed by the new wallet A with random partitions PoSt challenge.

   type RandomPoStChallenge struct {
       // Challenge deadline
       Deadline *dline.Info
   
       // partitions to challenge
       Partitions []int
   }
   
   type OwnerChangePoStChallenge struct {
       // random from network
       Random abi.Randomness
   
       // challenges produce according to the random
       Challenge []RandomPoStChallenge
   
       // PoSt submit deadline epoch
       CloseEpoch abi.ChainEpoch
   }
   
   // challenge window post result
   type SubmitOwnerChangePoStParams{
   	Deadline    *dline.Info
   	Partitions: []miner.PostPartition
   	Proofs:     nil,
   }

3. Generate window post for the challenged partitions (ONLY the data owner could do this).

   // extend the api to generate self-define window PoSt
   // Merge to Get Partitions
   challenge := OwnerChangePoStChallenge{}  // from challenge message
   var paritions []api.Partition = MergeAndGetParitions(&challenge) 
   
   partitionBatches := s.batchPartitions(partitions, NetworkVersion)
   posts := make([]SubmitOwnerChangePoStParams, len(partitionBatches))
   for batchIdx, batch := range partitionBatches {
       sInfos := getSectorInfo(batch)
       proof, ps, err := prover.GenerateWindowPoSt(ctx, actorId, sinfos, append(abi.PoStRandomness{}, challenge.Random...))
       posts = append(posts, SubmitOwnerChangePoStParams{
           Deadline:   di,
           Partitions: getPartitions(partition),
           Proofs:     proof.Proof
       })
   }

4. Submit the PoSt result signed by the new wallet A and waiting for network verification (ONLY the data owner could pass this verification).

   // Submit the above posts result signed by wallet A
   msg := SubmitMessage(nWallet, posts)
   
   // Submit the message before challenge.CloseEpoch

5. Use the new wallet A to submit a proposal to change the owner key to a specified new key if PoSt result is verified.

   # provide a api to make a owner key change proposal by the verified wallet A
   lotus-miner actor change-owner-key-proposal --proposal-key=wallet A --owner-key=new owner key

6. Use the new owner key to confirm the owner key change proposal.

   // use the new owner key to confirm the proposal
   lotus-miner actor confirm-owner-key-proposal --proposal-key=new owner key --owner-key=new owner key

Security Considerations

For this implementation a miner with the owner key lost requires a new key to submit a change owner key proposal and we use random PoSt challenge to verify the new key before it could make the owner key proposal.

ONLY the miner own the real sector data could generate and submit a valid PoSt proof for the random challenge, If the number of partitions or deadlines challenged are enough(Challenge over 50% of its power ?) and the whole operation is very safe and also means the data owner owns everything like collateral and rewards not just the owner key control everything.

Problems and Solutions:

1. FOR the CC sectors regeneration: We could add a random piece or mix some random bytes in the PC1 ticket that ONLY store in the local leveldb to make sure only the owner could regenerate the its CC sectors and the owner key change proposal only challenge the new sectors with random piece info or ticket with random bytes mixed.

2. AS for the random piece or random bytes we could backup the metadata frequently, this may brings some extra works but as least there are things we could do rather than losing everything while the owner key was stolen.

Draft FIP here: https://github.com/lionsoul2014/FIPs/blob/master/FIPS/fip-draft_ocpc.md

[lionsoul2014]

original draft FIP: https://github.com/lionsoul2014/FIPs/blob/master/FIPS/fip-draft_ocpc.md

[jbenet]

• It's a neat idea! 😄
• But sector data can be exfiltrated, and is not meant to be confidential. With this proposal, others could steal a MinerActor by getting access to the sector data, or the input parameters to the sealing process
• Also, with FVM, we'll see owner keys be Actors, to do all kinds of automatic processing.
• if you're having trouble with keeping keys safe, consider using a multisig?

[lionsoul2014]

1. the sector data do could be regenerated since the PC1/PC2 sealing calculation ONLY need a random ticket. We could mix some random bytes in the ticket or pack a random piece into the newly created sector and store them in the local leveldb, which means we need both the MinerActor the local random data to generate the CC sectors and that is almost impossible.
2. No matter Actors owner keys or multisig owner keys, the key point is owner key should not be that irreplaceable. even multisig there is still possible be stolen or lose.
3. What if everything still can continue as long as the data exists no matter what happened to the owner keys. i mean, data controls everything since we are mean to providing data service through Filecoin network.

[lionsoul2014]

The owner key of some miners in the mainland have been stolen, and the guy re-init the miner and changed the owner key, so they lost all the rewards and collateral, millions of dollars, But they still could provide data service and provide the valid window proofs.

I always thought this situation was weird cause the miners are hosting all their sectors data but they could do nothing ..... i mean we could do something to avoid this. Maybe from the next future version.

[de-authority]

It looks like we need a password to the private key instead of adding a random pieces to sectors.

[lionsoul2014]

It looks like we need a password to the private key instead of adding a random pieces to sectors.

private key password is a nice ideal and can help protecting the owner key.
i mean more than just the security of the owner key. As a storage project, Maybe it will be better that data controls everything and no matter what happens to the owner key. That is to say miner could get the block rewards and all the collateral as long as the data could provide service.

[de-authority]

Yeah. i got that point. sounds great.

[Aloxaf]

I think we should do more work to separate the signing process from the lotus node.
There is already a lotus-wallet, but it's lack of document and cannot run offline.

Currently, many storage providers do not keep owner address offline, because keeping it offline make withdraw and other operations difficult.

[lionsoul2014]

I mean more than just the security of the owner key. check the above responses please.

[lionsoul2014]

Chinese reader can access link: https://mp.weixin.qq.com/s/MpdBEcdMqDsoIAvvPgnn8w

[steven004]

I would like to provide some ideas to mitigate the risks mentioned in this proposal first:

1. Owner key protection (the key is offline):

• Never keep the owner key in the miner node, it should be offline, better to be in a cold wallet
• Use a multiSig address as the owner address; still the signer's key better to be offline

2. Separate the owner and beneficiary address (to be supported)

• See: discussion FIP Discussion: beneficiary address for a storage provider #253 & FIP PR Beneficiary address for miners #221
• The possibility might be lower to lose both the owner and beneficiary addresses

And, two questions, think about these scenarios:

1. Alice runs her node on cloud, or in an IDC, which is quite normal. One engineer who managing the cloud or the particular storage of the node checked the data and he knows Filecoin, that means, he knows the data, and could he be possibly change the owner address?
2. Emma hired some technical engineers to maintain her Filecoin node, do some necessary works, including managing the sectors, recovering them if any disk failures, should the technicians has the privilege to change owner? Or, when some one quit the job with the knowledge of some data, how to remove his possibility to change the owner address?

[lionsoul2014]

Nice ideals.
There are things we could to do to improve the current situation, whatever that could make the owner key not that irreplaceable

[Kubuxu]

Generate window post for the challenged partitions (ONLY the data owner could do this).

Assuming the data is not available directly to the attacker, there are two ways this can be abused:

1. Small SP can be taken over by re-sealing all the same sectors (if sectors are CC, they can be recreated based on on-chain data). This makes storing FIL for future sealing risky to the SP, the SP also looses the collateral.
2. Every SP has a partition that is currently growing, the attacker could aim to challenge only the small, currently growing partition. It is enough for the attacker to be able to only seal a bit faster than the victim to pull this off.

[lionsoul2014]

There are still problems waiting for solutions. i mean more about there are things we could do to make the owner key not that irreplaceable and whatever it is, data first is one of them, these are just my thoughts.

[dd45e640b42e6da7da96faee3996ef7c]

this creates massive problems for all available FIL lending options

(ONLY the data owner could do this)

everyone with access to the data could do this. this creates a way bigger problem than it tries to solve in my eyes

[tanqiangyes]

I think your solution will introduce new problems