LLHLS AES encryption (DRM)

[Tung2212]

Can there be an option for encrypting the hls stream using AES?
We can set key, IV to encrypt the segments and the data in the #EXT-X-KEY tag of the manifest file.

[getroot]

OvenMediaEngine does not provide AES encryption capability in LLHLS.

I don't know much about this feature yet. I think it's no different than using HTTPS (TLS Encryption) unless this feature works with per-viewer protection of the EXT-X-KEY URI. And to secure EXT-X-KEY URIs, integration with a DRM system capable of managing licenses will be required.

Please tell me if I'm wrong or have more opinions.

[Tung2212]

This feature indeed works with per-viewer protection if integrated with a DRM system.
And the integration with DRM systems can be done simply if we can set the key, IV and the data in the #EXT-X-KEY tag, for example (this is a sample for encrypted vod hls):
#EXTM3U
#EXT-X-TARGETDURATION:6
#EXT-X-VERSION:5
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-KEY:METHOD=SAMPLE-AES,KEYFORMAT="urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed",KEYFORMATVERSIONS="1",URI="WIDEVINE_INIT_DATA_URL"
#EXT-X-KEY:METHOD=SAMPLE-AES,KEYFORMAT="com.microsoft.playready",KEYFORMATVERSIONS="1",URI="PLAYREADY_INIT_DATA_URL"
#EXT-X-KEY:METHOD=SAMPLE-AES,KEYFORMAT="com.apple.streamingkeydelivery",KEYFORMATVERSIONS="1",URI="FAIRPLAY_INIT_DATA_URL"
#EXT-X-MAP:URI="init.mp4"
#EXTINF:6,
1.mp4
#EXTINF:6,
2.mp4
#EXTINF:6,
3.mp4
#EXTINF:6,
4.mp4
#EXTINF:6,
5.mp4
#EXT-X-ENDLIST

[getroot]

Thanks for the explanation. It seems to make sense if it is for integration with the DRM system. I'll add this to our backlog. However, it is not yet a high priority.

If so, it is necessary to allow the operator to set an external URL rather than providing the "EXT-X-KEY URI" directly from OvenMediaEngine. Also, does the DRM player use cookies for authentication when accessing the KEY URL? Or should the server provide different KEY URLs for each viewer? (For example, generate KEY URL as query string of HLS playback URL)

If there is a manual or standard specification that contains this content, it would be helpful if you share it.

[Tung2212]

The DRM player will get token from another location (e.g., website login system) and add to the DRM license URL (as a parameter or a header)
For example, this is how Shaka player do it: https://shaka-player-demo.appspot.com/docs/api/tutorial-license-server-auth.html

player.getNetworkingEngine().registerRequestFilter(function(type, request) {
// Only add headers to license requests:
if (type == shaka.net.NetworkingEngine.RequestType.LICENSE) {
// This is the specific header name and value the server wants:
request.headers['CWIP-Auth-Header'] = 'VGhpc0lzQVRlc3QK';
}
});

The actual DRM license URLs are set in the player side (again with a Shaka player setting belows, https://shaka-player-demo.appspot.com/docs/api/tutorial-drm-config.html), and different DRM systems have different standards, so I think the most flexible way is to allow the operator to add the #EXT-X-KEY lines directly.

player.configure({

drm: {
servers: {
'com.widevine.alpha': 'https://foo.bar/drm/widevine',
'com.microsoft.playready': 'https://foo.bar/drm/playready'
}
}
});

[getroot]

Ah, the EXT-X-KEY URL works just like the base URL. And according to the DRM standard, players set parameters in the base URL in various ways. Your explanation helped me a lot. thank you

[Tung2212]

Thank you too for adding this feature to your backlog. I'm looking forward to seeing this feature :D

[fairbairn]

I would say this is a pretty needed feature.

Placing the key within the playlist is rather useless in this day and age, but having support for the EXT-X-KEY URL would be great, as the security to deliver up the key can be more robust and external to the playlist.

DRM is a pretty hot topic as well. We have some groups that would be willing to help integrate their DRM platforms into OME.

[fairbairn]

Another cool suggestion would be to allow the encoding key used, to be delivered up by the AdmissionWebhooks interface, so we could provide a different key per unique stream (rather than globally to the OEM running instance).

When the stream starts, it sends over the request via AdmissionWebhooks to our custom Control Server, we provide back the key and the URI to be used in the playlist for key retrieval by the client. The key is used to encrypt the chunks, and the URI is embedded in the playlist. The video player itself will requery the URI to retrieve the key, which can hit our servers, and we can provide authentication and filtering to ensure only authorized users can get the key.

Since the key is unique per stream, our attack surface is reduced.

[getroot]

Since AdmissionWebhooks affect the entire stream, it is not suitable to provide properties specific to LLHLS. However, when I develop LLHLS Encryption in the future, I can add a URL to receive a key. I will consider this for future development.

[fairbairn]

That's fine. I would add that to allow the per-stream key capability to work, you should add query params on the URL that goes to the key server, so that it can deliver up the key contextually, per stream.

For example, if we specified ..

domain.com/api/getkey

for you to ingest into the playlist for key retrieval, it would be ideal if we had the option for you to pass..

domain.com/api/getkey?app=(app)&stream=(stream)

so if we were at live/test

domain.com/api/getkey?app=live&stream=test

In this way, the endpoint we provide for getkey can be intelligent and provide a per-stream key that's unique, so there's not one global key for everything.

[getroot]

It's been released!!!
#1375