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

Allow for long-lived key encryption keys (aka "master" keys) to increase performance #53

Open
steelejoe opened this issue Apr 28, 2015 · 5 comments

Comments

Projects
None yet
2 participants
@steelejoe
Copy link
Contributor

commented Apr 28, 2015

One of the use cases discussed in #41 was the inclusion of title keys in the media Initialization Data that are encrypted using some "master key" that the CDM previously acquired. The primary benefit of a system that provides title keys this way is to improve performance by reducing the number of key requests. However to realize this performance benefit, the CDM must be allowed to store keys in a location not dependent on a particular session. This is required because otherwise a request for a "master key" would be required for every session and you are just replacing one type of key request with another. Assuming that #41 is resolved, the usage of this feature can be invisible to the application.

Here are the main changes this would introduce:

  • Master keys are stored independent of a session. All other storage restrictions would apply.
  • Multiple sessions can access the same master key(s) simultaneously.
  • The usability of a master key is not exposed directly to the application.

Here are some of the spec changes I envision (there are more I am sure):

  • A definition of master key needs to be added. It is different from the current Keys definition which is specifically about title keys.
  • The remove algorithm might need to be modified to reflect that master keys are excluded from this processing. Or we could decide that such keys are not "associated with the session" by definition.
  • The Session Close algorithm might need to be modified to reflect that master keys are excluded from this processing. Or we could decide that such keys are not "associated with the session" by definition.
  • The Session Storage section would need to be modified to reflect that multiple session may have simultaneous access to the same "master keys".

We could add support to the Common PSSH for this feature, but I will leave that for another bug.

@ddorwin ddorwin added the blocked label May 5, 2015

@ddorwin

This comment has been minimized.

Copy link
Contributor

commented May 5, 2015

Per the telecon, blocked on #52.

@steelejoe

This comment has been minimized.

Copy link
Contributor Author

commented May 5, 2015

Responding to some discussion in the telco today --

@jdsmith brought up the question of whether these keys should be downloaded in persistent sessions to allow the app to better manage them.

I do not believe master keys should be required to be downloaded in persistent sessions because I don't believe the current session mechanism is capable enough to handle managing their lifetime. I agree that allowing the app to manage title keys is a good thing. However allowing the app to manage all keys (e.g. master keys) would expose a lot of not-easily-interoperable details for not much benefit.

Let me turn the question around -- under what conditions do we believe an app will need to manage these keys? And what type of management are we talking about?

The one use case I can think of is when a user wants to remove their footprint from the browser. In that case, rather than a discovery mechanism, I think a "clean slate" API which removes all persistent data stored by the CDM at once would be more appropriate.

@steelejoe

This comment has been minimized.

Copy link
Contributor Author

commented Oct 6, 2015

Issue #52 has been resolved, but issue #41 is still unresolved. I believe it will be difficult to resolve this without first resolving issue #41, so I proposed we wait.

@steelejoe

This comment has been minimized.

Copy link
Contributor Author

commented Oct 26, 2015

As a clarification, let me point out that this proposal is specifically talking about key encryption keys which are cached not key encryption keys which are baked into a CDM or key encryption keys that are acquired during the lifetime of a particular MediaKeys instance.

@steelejoe

This comment has been minimized.

Copy link
Contributor Author

commented Oct 27, 2015

Also as a clarification, I am not objecting to the milestone set for this feature of V.Next. This makes sense to defer until later, given the number of things we have to finish to get to CR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.