search

axiomatic-systems / Bento4

Full-featured MP4 format, MPEG DASH, HLS, CMAF SDK and tools
http://www.bento4.com
2.01k stars 482 forks source link

Does Bento have a way to add DRM (AES-128) on Subtitles/Closed Captioning? #515

Open TheDeadCode opened 4 years ago

TheDeadCode commented 4 years ago

Bonjour!

Do you know if it's covered by the HLS spec and Bento?

TheDeadCode commented 4 years ago

bump

barbibulle commented 4 years ago

Hi Felix, with HLS, subtitles and closed captions are treated somewhat differently. Closed captions are normally sent in-band. Depending on whether you use HLS with MPEG2-TS or with MP4 fragments, the way the captions are carried in-band is going to be different. For subtitles, HLS will use a playlist of WebVTT segments (which could be just one segment for the entire movie). In theory, the HLS RFC should allow WebVTT segments to be encrypted, with METHOD=AES-128, in which case the segment data is bulk-encrypted with AES-128 in CBC mode. However, I'm not sure how common that is, and which players actually support that. In the current version of the Bento4 tools, AES-128 encryption of WebVTT subtitle segments isn't supported, but that wouldn't be too hard to support, given that it is the same encryption as what's used for media segments, which is supported. Do you have an actual requirement for encrypting WebVTT segments, and a specific player in mind, or are you just trying to find if it is supported? (I'm asking, in case this is an actual requirement that becomes common, then it would make sense to implement it, provided that it is supported by standard players that can be used to test compatibility with).

TheDeadCode commented 4 years ago

We plan on using VTT with JWPlayer.

Our internal requirements for the project is for "All parts of the project which relates directly to the video stream, to be encrypted on disk and decrypted on the client at run-time. Examples of this are SAMPLE-AES or AES-128 for MPEG-TS fragments as well as VTT or CEA-708 Captions".

I believe last time I checked, JW supported it

barbibulle commented 4 years ago

This is an interesting requirement. Just encrypting the subtitles won't, by itself, give you any real level of security. What matters is where the decryption happens. With Audio and Video, the decryption happens in a secure DRM module, which performs the decryption and decoding in a way that's not open to the end user, and only the decoded data is then rendered back (and for Video, often with a secure path to the screen, on a computer display or over HDMI with HDCP protection). For subtitles, it isn't the DRM engine that's going to render those, as they are typically provided to the player itself for overlay on top of the video (especially in a browser environment). This means that 1/ you can't use the same key as the one used for Video and Audio, since that key will need to be provided to the (unsecured) player, and 2/ since the key is provided to the (unsecured) player, it is then trivial for the end user to access the decrypted data. As a result, encrypting the subtitles doesn't provide you any more security than just delivering the subtitle over HTTPS (i.e it is protected against an outside observer that may be intercepting the stream, but it isn't protected against access by the user who views the stream).

In your case, how are you planning on delivering the encryption key to the player? With HLS, you can point to the key by URL, but again, that provides no level of security. Or do you have a DRM engine in your playback environment that is capable of decrypting, decoding and rendering the subtitles as overlays on the video, without feeding them back to the browser?

TheDeadCode commented 4 years ago

Right now it’s only to prevent people who do not have access to certain video renditions (1080p, 2k or UHD) to access the key to decrypt some segments.

It’s only to provide rudimentary protection to deter lazy users (99% of users who see DRM, even simple DRM won’t even bother downloading sources).

It’s why we wish to provide at least basic DRM to the subtitles, just to deter the lazy users.

As for your question, about how we deliver the key, it’s basic AES-128 with --output-encryption-key, and on the server-side, when we get a request to fetch the key, we perform an RBAC check against the database, and serve the key if they are authorized.

It’s a pretty simple solution but it seems it has worked pretty well

Thank you!

Smith-Chris1 commented 4 years ago

I need this as well - we have a DRM solution for the mobile devices that are authorized to play back the media. Having encrypted webvtt subtitles would be very nice to ensure our content isn't easily accessible. Any word if this will be incorporated?