Broadcaster designated signers #13
Description
This post seeks to bring attention to this older issue proposing separation of the job creator and the segment signer roles for a broadcaster. The proposal was not implemented at the time due to time sensitivity relating to the initial launch of the network.
The basic idea of the proposal is as follows:
Currently, broadcasters are identified by a single account which is used to both deposit funds and sign segments (transcoders might need to submit broadcaster signatures for segments challenged for verification). Instead, we can allow broadcasters to designate a signing address when creating a job. A broadcaster can use one account to deposit funds for transcode jobs and designate another account to be responsible for signing segments for a particular job. The ability for a broadcaster to designate a signing address for a job has a few benefits:
- The broadcaster can be represented by a contract. The contract would deposit funds directly, but designate a separate address for signing which is necessary because contracts cannot produce signatures (which is why this use case is not possible with the current protocol).
- The broadcaster can rotate through signing addresses which is beneficial from a key security point of view. Since the account used to deposit/withdraw funds would be separate from the signing account, a hot-cold account hierarchy can be used where the cold account that is responsible for depositing/withdrawing funds can be secured offline and the hot account that is responsible for signing segments can be managed by the online Livepeer node. In the event that the hot account is compromised the broadcaster's deposited funds are still secure as long as the cold account is secure. Furthermore, broadcasters could use different hot accounts for different jobs by generating a new account right before it creates a job and then once the job expires it can (properly/securely) discard the account's keys. This use case can be especially helpful for broadcasters that would like to make larger up front deposits. At the moment, the safety of making a larger up front deposit is questionable since it is much easier for the broadcaster to lose control of the deposit if it loses control of its single account key.
An additional extension is to introduce an additional jobCreator account. A broadcaster would use its funder account to deposit and withdraw ETH funding transcode job deposits. funder would also set the jobCreator account which is authorized to create jobs for the broadcaster. jobCreator would submit the transaction to create a job and assign segment signing privileges to a separate signer account. The private key for the jobCreator account can live on an online machine and if it is compromised, funder can be secured in cold storage and transfer job creation privileges to a new account. This setup would preserve the current workflow of streaming into a node which will automatically submit a transaction to create a job if necessary.
As noted in the older proposal, with this change, we would need to defend against replay attacks:
Alice, a job creator, designates Bob as the signing broadcaster for a new job. Note: Alice and Bob could be the same entity. Bob signs and broadcasts segments 0-10 along with signatures for each segment. Eve, another job creator, then creates another job with the same streamId as Alice's job and also designates Bob as the signing broadcaster for a new job even though Bob does not know about Eve. Now, all of Bob's signatures are also valid for Eve's job.
We can do so by changing the broadcaster signed message format from sign(H(streamId, segNo, dataHash)) to sign(H(jobId, streamId, segNo, dataHash)). Transcode receipts would also need to include the jobId.
I originally considered an alternative solution which was to allow broadcaster to always designate a proxy contract that acts on their behalf and the JobsManager would validate broadcaster signatures by calling the proxy contract that maintains authorization logic for the broadcaster. However, this solution does not work because the broadcaster would grief the transcoder by sending it a valid signature, but changing the authorized address list of the proxy contract right before the signature needs to be validated on-chain. Generally, if signatures need to be validated, I don't think solutions that allow stateful modification of authorized address list work due to attack vector of forcing signature validation to fail by changing the authorized address list later on.