Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom more secure hls aes #2365

Closed
quanghuy1288 opened this issue Sep 9, 2019 · 5 comments
Closed

Custom more secure hls aes #2365

quanghuy1288 opened this issue Sep 9, 2019 · 5 comments

Comments

@quanghuy1288
Copy link

Is your feature request related to a problem? Please describe.
The lack of hls-aes is the key is exposed, so it can not protect content when every player with the link can play content.

Describe the solution you'd like

  • Usually streaming server like Wowza generate a hls key A for each encrypted content. I will encrypt this key to B by AES or RSA algorithm
  • Normal player can download hls manifest and key B but can not using it for decrypt content.
  • Player need a plugin/ custom player for intercepting when player download and using hls key. plugin/player need decrypt hls key from B to A before using it as hls key to decrypt content.
  • (Optional) Player regular request to an license server to check the license key which config with player at initiation, if license is invalid stop player for prevent lack of content.
@itsjamie
Copy link
Collaborator

itsjamie commented Sep 10, 2019

To a dedicated attacker, this wouldn't add much additional security because you would either need to include the additional key you used for encryption in your application code you embedded HLS.js into to decrypt this key. However, potentially adding a separate API to indirect EXT-X-KEY loading would allow you to achieve this?

I wonder if there are other use-cases for a kLoader API (similar to fLoader or pLoader) that would be made possible by adding something like this to 1.x.y.

@quanghuy1288
Copy link
Author

@itsjamie Could you link where kLoader API use-cases.

Infact our company using a cloud DRM service, but some device can not support DRM and the cost for running DRM is quite expensive. So, my above proposal is base on some flow from that cloud DRM service. I think this feature may be useful with many service/people who want protect content with a small cost.

@itsjamie
Copy link
Collaborator

This is it right here. :)

@quanghuy1288
Copy link
Author

@itsjamie i can not see the link

@robwalch
Copy link
Collaborator

robwalch commented Mar 3, 2020

We consider DRM contributions like #2194 and #1918. We also have to make sure that AES work with fmp4 #2259 but we don't have plans to implement custom solutions that would not work in Safari or with an EME scheme specific to the browser hls.js is running on.

@robwalch robwalch closed this as completed Mar 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants