New Transaction Type - New Forging Key - Allows delegates to the change key used for block signatures

[Nimbus76]

Issue:

To enable forging on a delegate’s Lisk node, the delegate must either insert the passphrase corresponding to the delegate’s primary key into the config.json file of the delegate's Lisk node or send an enable forging command to the node’s API. If the passphrase is compromised*, a third party will be able to impersonate the delegate on the network. This would open the door for several attacks including a) instigating network forks through double-forge attempts, and b) censoring transactions from the Transaction Pool, thereby reducing network throughput or delaying transactions.

Under the current protocol, the primary method to mitigate the loss of network security resulting from the compromise of a delegate’s primary key passphrase is for the delegate’s voters to unvote the delegate. This solution has several drawbacks including delayed response to network attacks while waiting for the community to unvote the compromised delegate, and incentivization of the delegate to avoid to taking action to rectify a potentially compromised primary key because of the risk that the delegate will lose forging position as a result of disclosure. In addition, the economic cost to voters associated with unvoting a single compromised delegate’s account could soon total several hundred thousand dollars in network fees.

Proposed Solution:

A new Transaction Type (“New Forging Key”) should be implemented. The “forging key” is the public key of a newly created keypair. A delegate’s most recently registered “forging key” should be recognized by the network as the delegate’s sole authorized key for block signatures following the registration. If a delegate has not registered a "forging key," the network should continue to recognize the delegate's primary public key as the delegate's authorized key for block signatures. Following creation of a "forging key," the delegate's primary and secondary keys remain unchanged, and are still utilized for the purpose of creating transactions, vote arrays, account inquiries, etc.

The proposed JSON for the “New Forging Key” transaction is as follows:

{
    "nethash": nethash,
    "type": 8,
    "amount": 0,
    "senderPublicKey": Public key of the sender,
    "timestamp": Timestamp,
    "recipientId": null,
    "signature": Signature of the data block,
    "id": Id of the transaction,
    "fee": 10000000000,
    "senderId": Id of the sender,
    "asset": {
        "delegate": {
            
            "publicKey": The public key of the user (the sender),
            "newForgingKey": The public key of delegate’s new forging keypair, 
        }
    }
    ...
}

The proposed transaction should require additional signature for accounts where a second public key has been registered. Inclusion of the blockchain’s nethash, as suggested in Issue #1610, is recommended.

With this new transaction type in place, a delegate suspecting compromise or unauthorized use of a forging key, or as a matter of hygiene, will have the ability to transfer forging authority to a new key without the necessity of requiring mass unvoting of the delegate to accomplish the transfer.

* Compromise of a delegate’s primary key can take several forms. For example, the delegate’s server could be hacked through remote or local access. Many delegates utilize cloud services for their servers and do not control physical access. In addition, delegates have been known to share their primary key passphrases with other delegates or to assistants in order to assist with the operation of the delegate’s forging node. Once stolen or shared, anyone with knowledge of the delegate’s primary key has an enhanced ability to conduct network attacks. This access cannot be revoked under the current protocol.

[shuse2]

This issue requires protocol change.
For further discussion, please go to https://research.lisk.io/