HLS: Consider providing hooks for non-standard (full segment encryption) DRM schemes

[bjitivo]

[REQUIRED] Searched documentation and issues

Tell us where you’ve already looked for an answer to your question. It’s
important for us to know this so that we can improve our documentation.

I searched on Google for information on integrating the DRM system that we are using with ExoPlayer. I found some discussions but they were always closed by the ExoPlayer team as 'not something we will support'.

[REQUIRED] Question

Describe your question in detail.

I would like to know if the ExoPlayer team would consider a change that would enable what I call "HLS whole segment decryption". The motivation for this change is that some DRM vendors provide solutions that require that the mechanism for decrypting HLS segments be more controlled by them than the ExoPlayer code base currently allows.

The gist of these DRM vendors' design is that they implement their own mechanism for downloading the segment encryption key and decrypting the segment, given these inputs:

1. The segment decryption key URI
2. The initialization vector
3. The entire segment as bytes

I do not know the reasons for these design choices, but I can guess:

• HLS as specified allows the client to request the decryption key from the key URI and perform the decryption of the segment
• However, naive implementations of this mechanism may make the key 'sniffable' by motivated individuals who may have means for intercepting data on the host device, such as somehow acquiring memory snapshots, or side channel attacks on the processor to detect operations on the key that reveal details that could be used to help break the key
• So these vendors provide obfuscation and risk mitigation solutions that do things like scrambling the keys in memory, implementing alternate algorithms for decryption that are not as vulnerable to side channel attacks, never piecing the key together except in CPU registers that are very difficult to sniff from the outside, etc
• Finally, the mechanism for fetching the key itself may be more than a standard HTTP GET operation - the vendor may implement some means for having the client provide authentication credentials at the time of requesting the key from the key URI and may do so using nonstandard (outside of normal HTTP authentication mechanisms) means

This last part seems to me like it would violate the HLS spec; but be that as it may, it is a reality that these systems exist and I don't think it would be very hard to make ExoPlayer more amenable to supporting them.

Currently ExoPlayer assumes that if segments are encrypted in a way that is described by standard HLS tags (EXT-X-KEY) that it should:

a. Fetch the decryption key as a precondition to creating a new HlsMediaChunk for the segment
b. Create an Aes128DataSource to perform a decryption step before providing the raw data of the chunk

Neither (a) nor (b) is desirable in the case of "HLS whole segment decryption". What I would propose is some mechanism (I haven't yet worked out exactly the cleanest way to do this in ExoPlayer) where instead of doing (a) or (b), the HlsChunkSource would know to create a different type of DataSource which would be given the key URI and IV directly. After that, the DataSource would be used as normal within the HlsMediaChunk without any further management of decryption by the standard ExoPlayer classes. This special DataSource would know how to use the 'original' DataSource which downloads the encrypted segment, in combination with the key URI and IV, to decrypt and make available the raw decrypted bytes of the segment. This mechanism would be amenable to users of the ExoPlayer API providing the action implementation of this decryption; no actual implementation of this would be provided in ExoPlayer, this would simply be a mechanism for allowing applications to easily use "HLS whole segment decryption" by providing their own decryption mechanism.

Such a mechanism would provide the ExoPlayer part of the solution to the following ssues (and possibly more I have not found):

#3781
#1627
#5512
#4820

I am not suggesting going so far as to integrate Verimatrix DRM support directly into ExoPlayer; I think this would be inappropriate because from my reading, Verimatrix DRM requires HLS servers and clients to operate in non-HLS-spec-compliant fashion and I don't think this sort of thing should be codified in the ExoPlayer code base. But making the code base amenable to these systems via the design I describe above might be an acceptable compromise.

The reason I ask this question is that I can either do the more detailed work of creating the mechanism I describe above, or can just 'hack it in' via simpler local changes. I do not want to embark upon the former approach if a pull request with these changes wouldn't be accepted by the ExoPlayer team ... so, please advise. Thank you!

[ojw28]

I think this is the kind of thing where we'd take a pull request provided that the changes are minimal and non-invasive. For example a small set of hooks that are sufficient to let you do what you need to do. I don't think it's something we're going to prioritize on our side, but if you want to investigate how this might be done and propose a pull request, please do so!

[bjitivo]

Thank you for your response, I will get to work on it and make a hopefully acceptable pull request.

To be honest, I am struggling a little bit to find a 'clean' way to create this hook that does not push tons and tons of constructor arguments from HlsMediaChunk all the way up through many intermediate classes to the media segment factory. The "cleanest" in the sense of being least disruptive to the current architecture is to create a subclass of DataSource that knows about being told to operate in this special mode (supplied a key uri and iv), and having HlsChunkSource do an instanceof to see if the data source factory ended up making one of these special DataSources to be used in this special way.

It's unsatisfying because code that relies on instanceof to inject special behavior just seems gross. And yet I have not yet found a non-disruptive way to do this otherwise ... still investigating ...

Thanks again!

[AquilesCanta]

Brief comment on this: Wouldn't it be possible for custom encryption methods to use the fields available in EXT-X-KEY to decrypt segments as necessary?

For instance, let's say verimatrix use their own encryption method, so samples are tagged as follows:

#EXT-X-KEY:METHOD=VERIMATRIX-AES-128,URI="https://path.to.data/necessary/for/decryption"

And then we pass the EXT-X-KEY data to the HlsDataSourceFactory. Would that work?

[bjitivo]

Custom DRM solutions are inflexible as they are created by third parties not particularly interested in working with open source projects (unfortunately). In this case, the Verimatrix solution does not emit custom METHOD tag, so what are suggesting would require changes on their part, which is unlikely. Furthermore, that METHOD is not defined in the HLS spec and so would be nonstandard, so you'd be moving from one nonstandard mechanism to another nonstandard mechanism, which seems like a sideways move to me. Finally, the important thing is that a custom HLS data source be possible so that it can handle the decryption according to requirements of the DRM library, and I'm not sure how what you propose would prevent the changes that need to be made to support custom HLS data sources.

But thanks for the suggestion ... I'm all for finding ways to do this as non-intrusively within ExoPlayer as possible, but my local change is about as non-intrusive as I can imagine would be possible, it's only about 8 lines of code changed within ExoPlayer and the addition of one extra interface that you only need to even know about if you are doing these custom decryption mechanisms.

[AquilesCanta]

by third parties not particularly interested in working with open source projects

So who would implement the decryption components?

Furthermore, that METHOD is not defined in the HLS spec ...

So what are they using for signalling encrypted segments?

Can you please provide an example of what media would look like?

[bjitivo]

The DRM library implements the decryption. An application implements a DataSource.Factory instance (sorry I neglected to mention this in my previous comment) which supplies DataSource instances which implement a new interface "HlsDecryptingDataSource".

When the HlsChunkSource detects that a segment is encrypted, it checks to see if the data source it has been provided is an instance of HlsDecryptingDataSource, and if so, calls a method on it to get an instance of DataSource to use to actually provide the decrypted data. It is up to the implementation of HlsDecryptingDataSource to arrange things so that the decryption happens according to the requirements of the DRM library.

Unfortunately, I cannot provide code, because our agreement for this is now deep within the hole of our legal department awaiting approval :(