Open yondonfu opened 5 years ago
Agreed that it'd be very useful to separate the job creator and segment signer. For the proposed change:
sign(H(jobId, streamId, segNo, dataHash))
Do we still need streamId here, since that can be derived from the jobId
?
Also, since the jobId
/streamId
seems to be mostly benefit the transcoder's own checking (ensuring the submitted segment is associated with a legitimate job), perhaps we could generalize a bit by simply using an opaque token that's selected by the transcoder. More information here: https://github.com/livepeer/LIPs/issues/14
This is a fantastic idea. I think many B operators who are security-aware won't feel comfortable securing significant value using the same hot key they need for job signing. IMO this improvement is needed for adoption at scale.
What's the right process for discussing this issue's priority and best time to implement?
@yondonfu @ericxtang
I think many B operators who are security-aware won't feel comfortable securing significant value using the same hot key they need for job signing. IMO this improvement is needed for adoption at scale.
Agreed. While this proposal was originally written for the V1 protocol, this separation of responsibilities for keys can apply for any payment protocol that involves on-chain deposits and signing of off-chain messages. I would propose incorporating this into Streamflow.
@yondonfu thanks! @ericxtang would love to get your take on this!
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:
An additional extension is to introduce an additional
jobCreator
account. A broadcaster would use itsfunder
account to deposit and withdraw ETH funding transcode job deposits.funder
would also set thejobCreator
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 separatesigner
account. The private key for thejobCreator
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:
We can do so by changing the broadcaster signed message format from
sign(H(streamId, segNo, dataHash))
tosign(H(jobId, streamId, segNo, dataHash))
. Transcode receipts would also need to include thejobId
.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.