HTTP live streaming with encryption

Question

I am trying to understand how the HTTP Live Streaming protocol that Apple supports on their iOS devices as well as on Safari protects the key that unlocks the content.

The way I understand it, the .m3u8 file holds the whole thing together and references the content (in MPEG2 TS container, AES 128 encrypted) and the key to the TS file.

Like in this example:

   #EXTM3U
   #EXT-X-MEDIA-SEQUENCE:7794
   #EXT-X-TARGETDURATION:15

   #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=52"

   #EXTINF:15,
   http://media.example.com/fileSequence52-1.ts
   #EXTINF:15,
   http://media.example.com/fileSequence52-2.ts
   #EXTINF:15,
   http://media.example.com/fileSequence52-3.ts

   #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=53"

   #EXTINF:15,
   http://media.example.com/fileSequence53-1.ts

Assuming a browser based playback where the <video> element is fed a m3u8 file in the "src" attribute. In this case, even if the key is delivered via https, how can I make sure that the user does not simply enter the https URL in his browser and saves the key to his hard drive? The way I understand the mechanism, the key download is done by the <video> tag as it plays the m3u8 source using the browser's https stack -- how is the legitimate client inside the browser distinguished from the user just typing it into the address bar? This must be really obvious, but I just don't see it...

All the best,

dansch

Answer 1

how can I make sure that the user does not simply enter the https URL in his browser and saves the key to his hard drive?

You can have an SSL client key/certificate in the app, and thereby authenticate "the app" for playing the content. Then you'd avoid leaking your content to other devices than your app.

But that would mean you'd need to somehow hide your ssl-key/passphrase inside the app. And there are unfortunately also problems getting the video player on iOS to use the ssl key authentication...

Answer 2

Some interesting pointers can be found here: https://developer.apple.com/library/content/documentation/AudioVideo/Conceptual/AirPlayGuide/EncryptionandAuthentication/EncryptionandAuthentication.html

This will require custom work in iOS, but also in Android and web players.

• Serve keys from a protected HTTPS realm. Before playback begins, your app can use NSURLConnection to authenticate itself, providing credentials that are kept hidden.
• Use cookies over HTTPS. Your app can make a connection to an HTTPS server and authenticate the app in an app-defined way. Your server can then issue a cookie that applies to the key URLs. You should set the cookie to expire long after playback is complete. The server must then require the presence of a valid session cookie in future GET requests for the keys. For maximum reliability, if the expiration date is in the near future, the server should update the cookie’s expiration date in its response to future GET requests.
• Specify the keys in the .m3u8 files using an app-defined URL scheme. The app should register a custom NSURLProtocol to handle requests for those URLs. The player then calls back into your app when it needs to load a key URL; your app can then obtain the key using a secure side channel and can provide it to the player.

If you're only targeting iOS, then you should use Apple Fairplay DRM which handles the authentication of the keys.