Secure the RTMP of Streaming Back-End

[criticaltv]

Is your feature request related to a problem? Please describe.

When publishing an RTMP stream into Livepeer running in -broadcaster mode, the Publisher's stream_key is encoded into the URL for a Viewer to use to play the stream.

This introduces opportunity to deny service on specific URLs, for example, if you would like to stream using http://1.2.3.4:8935/stream/{stream_key} then a rogue Publisher can stream using your {stream_key}, and deny you service.

Describe the solution you'd like

I would like some kind of translation mechanism to translate a) the {stream_key} provided by the Publisher, into b) the stream identifier coded into the URL to allow a viewer to access the stream.

This would make it hard for a rogue Publisher to deny service using a specific stream_key

For example, a simple (but insecure) method could be for:

• Publisher uses their own Ethereum private_key as stream key
• Broadcaster simply uses this to generate the associated public_address using sha256
• Broadcaster publishes user's stream at http://1.2.3.4:8935/stream/public_address

Describe alternatives you've considered

A more comprehensive potential solution would be to use sha256 and Ethereum's signing functionality to allow a Publisher to generate their own stream_key by signing a message, which a Livepeer node could validate.

The flow could be something like:

• Broadcaster starts with -broadcastSecret secret
• Publisher uses private key to sign the secret to create signed_secret
• Publisher passes in a string consisting of their public_address concatenated with the signed_secret
• Broadcaster validates that the private key associated with the public address signed the secret
• Broadcaster publishes user's stream at http://1.2.3.4:8935/stream/public_address

Additional context

Livepeer have implemented RTMPWebhookAuth, which appears to be designed to assist such implementations:

https://github.com/livepeer/go-livepeer/blob/master/doc/rtmpwebhookauth.md

This solution of encoding the Publisher's public address into the stream URL can be very useful in terms of directing payment from Viewers to Publishers.

Specific deliverables

• Open a Pull Request to Livepeer's go-livepeer repo, from a clone of go-livepeer's repo, containing the code changes to allow such a system to be enabled by passing in the appropriate flag to -broadcaster

• Discuss any feedback with the Livepeer team, and respond to the feedback

• Bounty will pay out when the PR is approved.