Welcome to this overview of media protection systems. The strongest systems use Digital Rights Management and protect media during and after playback. Other systems expose information during playback and cannot protect media afterwards, but offer some protections and are easier to setup.
From IBM “Encrypted Video Streaming”,
When interviewed on the purchase decisions behind streaming technologies, 83 percent of corporate executives cited the importance of securing content from those not authorized to view it. Of those who worked in companies that use live online video more than 100 times a year, 66 percent cited content security as either mandatory or very important to the purchase decision.
| security | fees | setup | maintenance | |
|---|---|---|---|---|
| Signed URL | soft | none | easy | low |
| Encrypted Stream | soft | none | easy | low |
| Digital Rights Mangement | strong | vendor | hard | possibly high |
cloudfront.net/stream-123.m3u8?token=signed
Signed-urls return media according to policies at the signature. They offer weak protection, because signatures are publicly available and re-usable to request the “protected” media.
details
cfsign.getSignedUrl( 'http://ex.cloudfront.net/path/s3/object', {
keypairId: process.env.PUBLIC_KEY,
privateKeyString: process.env.PRIVATE_KEY,
expireTime: 1426625464599
});
Signed-urls can block other web sites from hotlinking media by using policies that refuse requests from unknown domains. They can also deny requests that occur outside specified time periods. Signature key pairs can be rotated in-frequently to invalidate older key pairs.
Signed URLs that are valid for such a short period are good for distributing content on-the-fly to a user for a limited purpose, such as distributing movie rentals or music downloads to customers on demand.
To use signed-urls, we would serve media from CloudFront urls only, disabling S3 urls. We would add an AWS signing account and “as soon as you add the account, CloudFront starts to require signed URLs […].”
To prevent hotlinking, a CloudFront origin for writing cookies would be needed to support domain-enforcing cookie-signatures
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:9
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-KEY:METHOD=AES-128,URI="https://iconicengine.com/key",IV=0xecd
#EXTINF:8.33333
fileSequence0.ts
#EXTINF:8.33333
fileSequence1.ts
#EXT-X-ENDLIST
Encrypted-stream playlists define a URI for requesting a media-decryption key. They offer weak protection, because decryption keys are exposed and re-usable to decrypt “protected” media.
details
HLS_ABRconfig.Playlists[0].HlsContentProtection = {
Key: 'The Key',
KeyMd5: 'The MD5 digest of The Key',
KeyStoragePolicy: 'NoStore',
LicenseAcquisitionUrl: 'https://iconicengine.com/key',
Method: 'aes-128'
};
When EXT-X-KEY is defined, the IETF streaming spec mandates the player use the key. By refusing to send keys to requests from unknown domains, web sites can be blocked from hotlinking the media. Encrypted streams are useful with small trust-worthy groups of people, authenticating themselves.
Media can be encrypted with multiple keys, rotated across playlists and segments. Not supported by Amazon's transcode services.
{
widevineLicenseUrl: 'http://drm-proxy.iconicengine.com/license',
emeEnabled: true
}
A DRM license is required to play protected media. DRM offers strong protection, because every media playback requires a license, even when media are copied from someone with a license. Primary keys are not exposed and each license is a unique intermediary key required for playback.
details
| Microsoft | PlayReady |
| Apple | FairPlay |
| Widevine, licensee-only documentation |
Media are encrypted and packaged in a special way for DRM playback. Doing this requires packaging from a licensed DRM “provider” (or becoming a licensed provider ourselves). The provider should handle output for three main DRM systems: Apple FairPlay, Microsoft PlayReady and Google Widevine. Two content will be generated for each media because Apple FairPlay HLS implementations use the CBC encryption algorithm and Widevine and PlayReady implementations use CTR.
The provider should probably come from Amazon's list of providers integrating with AWS MediaConvert through Amazon's SPEKE prototcol. To give an idea of costs, a pricing table is seen here for German-based provider castLabs. Our own implementation details will be mostly determined by the provider we choose to integrate with.
DRM playback requires a new license request for each media segment. This transaction is where we control who gets a license. If we do not manage this transaction, the provider may only enforce Geo-blocking, device-filtering, concurrent-stream-limiting and "output protection" (if content can be rendered to external devices).
We hope the provider maintains the license session for us so that we do not need to manage a proxy-service for all license requests. Indicators we may not need a session proxy-service are this issue thread for hls.js, discussing auth-header setup and this comment (also hls.js) where a contributor mentions "[reusing] an EME license instead of making a license request for every variant playlist [...] licenses can be reused on a key session for every variant."
If the provider cannot maintain a session for us we'll have a lot more work on our hands.
Within the DRM ecosystem are competing standards, third-party vendors, black-box components, license-restricted documentation and other obstacles. Useful jargon are explained here with links to more canonical definitions.
Good overviews of DRM are published by Microsoft and good explanations of DRM browser playback are here from Google.
DRM and media
Browser DRM
mediaSource = new MediaSource();
mediaSource.addEventListener('sourceopen', () => { /*...*/ });
navigator.requestMediaKeySystemAccess('com.widevine.alpha', config)
CDMMediaKeySession.generateRequest();
AWS Integration
Q. What about Adobe's “PrimeTime” DRM?
The web player uses hls.js to play HLS streams and it only supports Widevine (and, experimentally, Microsoft PlayReady). Additionally, the AWS MediaConvert transcoder only supports Widevine, Microsoft PlayReady and Apple Fairplay.
Q. This reddit thread indicates Widevine L3 is cracked!
L3 is bad protection. L1 is used for anything decent. L3 uses a key to decrypt media, but un-encrypted media are used outside the decryptor. L1 stays protected throughout the pipeline to keep raw video inaccessible.
This happens at an OS/GPU level. Only protected resources may access the encrypted-media and media cannot be copied to un-protected resources.
L3, on the other hand, can be decoded to unprotected resources —better than nothing, but easily defeated.