Re: Unique identifiers and WebCrypto

Dear Seetharama, Dear Colleagues,

On 2012-11-07, at 22:43 , Seetharama Rao Durbha <S.Durbha@cablelabs.com> wrote:

> [...]
>> For keys on tokens, like smart-cards, etc. there is indeed a key discovery problem, which we don't yet have a detailed proposal for. There would need to be some way for the web application to ask for a list of keys with certain properties. User permission would be asked for before exposing the list to the application and if user permission is denied this should be indistinguishable from the key not existing (as far as the web application is concerned).
>> 
>> For pre-provisioned origin-specific keys of the type I am most concerned about, we would expect these to have well-known identifiers (at least, well-known to the origin in question) and so the discovery problem is solved that way.
> 
> Well, the question is – even if the app provides all necessary indices for a key, and such a key exists – should the browser inform the app that such a key exists? Depending on how easy it is to get to / guess such indices, as pre-existing keys do not have an associated origin, any origin will be able to ask for such keys, and get to know their existence. So, what is the value in hiding keys? Cannot we let all applications know about the existence of yet-to-be-bound / unbound keys?
> [...]

In the Pay TV world, and on the DVB side of things, we came to the following solution for this problem:

We assign unique identifiers to the operators of DRM systems. This is done through a registry. It is important to note that the IDs are issued to operators, not vendors. Hence, the ID is linked to a service (e.g. "ACME, Inc. IPTV"), and not to the DRM maker (e.g. "Microsoft").

Then, any security appliances (Smart Cards etc.) register with the host platform using this operator ID. When an application contains security features of a certain operator, it can query the host for security services under its operator ID. The host reports any security appliances of that ID back to the application, and then establishes communication channels between the application and those appliances.

Any subsequent communication between the app and the appliances is opaque to the host, and solely defined by the respective DRM operator. He wrote the app, and he sent you the Smart Card; so these two should know how to talk to each other.

This scheme is a nice separation-of-concerns design, since the host platform can be agnostic of the number and nature of keys, and the DRM operator is not dependent of any specific security features supported by the host platform.

This is important, because what keeps secure stuff secure in the long run, is the renewability. If too many security details are built into the host platform, and one operator's security scheme becomes compromised, all host platforms need to be updated to accommodate the fix for that one operator (even if 99% of all platforms out there don't even use it). With this separation-of-concerns design, the compromised operator will "just" need to update the Smart Cards (send out new ones or download a new firmware), and update their Web app. It will only affect that one operator and his clients; but nobody else.

Also, asking user consent, or refraining from doing so would be at the sole discretion of the DRM operator. When and what consent needs to be asked, depends on many legal and contractual factors. So I personally would be hesitant putting this in any standard that aims for global deployment.


Finally, a feature that would reveal how many keys a DRM operator provides, and would even reveal information about them (properties) to third parties, might be seen as not acceptable by some vendors. So my suggestion would be to actively reach out to the DRM and CA vendors and ask them about their views.


Hoping to have helped,

  --alexander

Received on Friday, 9 November 2012 11:06:46 UTC