Security overview

Last Updated 4 months ago

Introduction
This article explains how to build a website which uses secure video streaming. Different solutions require different levels of security and Quickchannel supports many features to meet the varying requirements.

When we talk about security, there are a few different concepts which are often grouped under the same umbrella:

  • Video content cannot be downloaded
  • Videos cannot be distributed to other users
  • Videos cannot be watched by unauthorized users

As you will see below, Quickchannel has technology that addresses each of these problems.

Ways of protecting content
Quickchannel supports multiple ways to protect video content from being viewed and/or downloaded by unauthorised visitors. Below are the different functions enumerated:

  • HTTPS embed codes - Platform resources (such as the player and images) are hosted with SSL encryption.
  • Player handshake - The player shares a secret token with our streaming servers, which is used to identify the player as an authorized consumer of content. This means that only the Quickchannel player can download the video stream and that the stream is protected from downloads by an unauthorised adversary (Only available for accounts using legacy setup).
  • IP/domain locking - Video playback is restricted to users from certain IP ranges or certain domains. This is useful if you only want your videos to show in your intranet.
  • Dynamic IP locking - Each time the web page is presented to the user, a unique dynamic video link exclusive to the particular end user's IP address is created. This method makes the video link available to any user which has access to the page that the video is published on, but the video cannot be viewed by anyone with a different IP address.
  • Geo blocking - Using the user’s IP address and an IP location database the service can block out users based on the country that they are located in.

Dynamic IP locking explained

image


This is a sequence diagram that explains how dynamic IP locking works. The steps are:

  1. End user authenticates with the protected website, for example using a login or a VPN solution.
  2. The end user navigates to a page with a video that shall be secured.
  3. The protected website requests an embed code from Quickchannel which is locked to the IP address of end user and presents this embed code to the end user.
  4. The end user can now play the video but cannot share it with anyone because of the IP restriction.

Recommended security solution
Quickchannel recommends the following setup to build a secure video streaming service:

  • Use secure authorisation on your website and display embed codes using dynamic IP locking. This means that videos are only visible to authorised end users.
  • Instead of dynamic IP locking a normal IP locking method can also be used if content is only to be displayed on an intranet with a fixed IP range.
  • Optionally, use geolocking to restrict your content to a certain region.

Example code

Below is example code which shows how to generate a dynamically IP locked video embed code using the REST API. Simply include the userip as a parameter to the embed call and the resulting embed code will only work for a user with the specified IP address.

REST API in Python

#!/usr/bin/env python3

import requests

mediaid = ''   # set to the mediaid of the video to embed
token = ''     # set to access token generated in the Console
accountid = '' # set to your Account ID
userip = ''    # set to the IP address of end user

url = 'https://rest.screen9.com/{}/media/{}/embed?userip={}'.format(
    accountid, mediaid, userip
)
print(requests.get(url, auth=(accountid, token)).json()['embed'])

WebRTC security

Quickchannel uses WebRTC for ingesting video from camera and/or screencast directly from the user's web browser into a live event, and well as for real time, low latency preview of the Live Mixer Studio output.
The Studio user is first authenticated via an HTTPS API using a stream key that is unique for every live event. Potential peers that fail this authentication step are simply rejected by the WebRTC gateway. All data traffic between authenticated peers is encrypted using DTLS, as mandated by the WebRTC standard.

This website relies on cookies to function, but no personal data is ever stored in the cookies.
OK

Loading ...