The Netflix use-case - Another take

Netflix claims that they need support for pre-provisioned keys in the Web Crypto API.

Pre-provisioned keys come in two flavors, Connected and Embedded.  The satellite TV industry already uses externally supplied cards for media access and decryption but it seems that the Internet-powered media providers do not intend going this route which is understandable since ISO-card readers remain an unusual peripheral outside of TVs.   The need for physical distribution is also a factor that speaks against card solutions.

That is, pre-provisioned keys in the Netflix use-case is rather about Embedded keys.

A direct approach would be that device makers insert some kind of Netflix-specific keys during device personalization/manufacturing.  Maybe this is how its done today?

However, there is another solution to this issue that has considerable advantages [*] and that is rather embedding an application-neutral device-credential in the form of an X.509 certificate + private key which is subsequently used to securely provision other keys.  The identity of the device certificate has multiple uses like:
1. Identifying the brand of the device
2. Identifying the exact unit

#1 can also be used to identify the cryptographic strength of the device key container which may not be an issue for the streaming media industry but is paramount for payment credentials.  Yes, the Google Wallet [of course] builds on this.

#2 is quite interesting for secure enroll of devices in both BYOD and consumer-scenarios.  For DRM-purposes the binding of a subscription to a specific device is often a requirement.

PrimeKey (my current employer) have through a our customers already deployed more than 500 Million device certificates so the concept is by no means new or "experimental".

What's currently missing is a universal enrollment system that supports on-line provisioning of application-specific keys secured by pre-provisioned device credentials.
Although a standard may be very far away, there is at least a proposal on the table:

http://webpki.org/papers/keygen2/sks-keygen2-exec-level-presentation.pdf
http://openkeystore.googlecode.com/svn/trunk/resources/docs/sks-api-arch.pdf

The SKS/KeyGen2 scheme is already running in Android (albeit in a proof-of-concept mode because a platform-level implementation would be completely ridiculous without Google's blessing):

http://code.google.com/p/openkeystore/source/browse/trunk/webpkisuite-4-android

How keys that are not provisioned through the Web Crypto API can be used by the Web Crypto APi is another and hopefully generic issue.

Anders Rundgren

*]
- Works for any computing device
- Limited impact on the device manufacturing process
- Independent of service-providers

Received on Friday, 16 November 2012 05:45:32 UTC