Device Certificate Provisioning

635 views
Skip to first unread message

David Liu

unread,
Mar 16, 2018, 1:01:42 PM3/16/18
to cobalt-dev
Hi,

From EME spec, https://www.w3.org/TR/encrypted-media/#individualization , device provisioning is called individualization.

When doing device certificate provisioning, Widevine will generate a URL-encoded base64 signed message and ask application to send the message to the provision server, since CDM has no networking capability of its own. The message is then concatenated to a pre-defined provision server url and the application needs to send request to that url using POST method and retrieve device certificate.

However, according to EME spec [8.6.1 Direct Individualization], this provisioning process MUST be performed by the user agent and MUST NOT use the APIs defined in this specification, so we cannot ask client Javascript to do it through EME APIs.

Currently we pass the url to cobalt through a DRM callback function but it seems there is no function to handle the provision request. There is a function, DrmSystem::OnSessionUpdateRequestGeneratedFunc, in cobalt/media/base/drm_system.cc that takes a url parameter but does not use it at all. Is that intended?

Is there any suggestion about how to handle this provision request? If it should be done inside cobalt, where is the best place to do it and how to do it using existing cobalt functions? Are we supposed to use XMLHttpRequest class in cobalt/xhr/xml_http_request.h or URLRequest class in net/url_request/url_fetcher.h or other class?

Thanks
David

Maksym Motornyy

unread,
Mar 16, 2018, 1:28:53 PM3/16/18
to David Liu, cobalt-dev
Hi David,

According to the EME spec, individualization "must be performed either directly by the user agent or through the application". Cobalt doesn't support the former, so web apps are expected to support the latter, namely "app-assisted individualization" (https://www.w3.org/TR/encrypted-media/#app-assisted-individualization).

Practically speaking, use SbDrmSessionUpdateRequestFunc callback to generate individualization requests, just like you do it for license requests and renewals. YouTube player (I'm assuming you need Cobalt for YouTube) will handle the request and send it back to CDM through SbDrmUpdateSession.

Sincerely,
Maksym Motornyy.

You received this message because you are subscribed to the Google Groups "cobalt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cobalt-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

David Liu

unread,
Mar 16, 2018, 6:57:47 PM3/16/18
to cobalt-dev
Hi Maksym,

I tried to pass the individualization message through SbDrmSessionUpdateRequestFunc callback but SbDrmUpdateSession did not get called afterwards, neither in https://www.youtube.com/tv or in 2018 EME Conformance Tests.

For "app-assisted individualization" in the EME spec (https://www.w3.org/TR/encrypted-media/#app-assisted-individualization), the message type should be "individualization-request". However, the message type seems always be set to "license-request" in MediaKeySession::OnSessionUpdateRequestGenerated() in src/cobalt/dom/eme/media_key_session.cc

Could you please help confirm if "app-assisted individualization" is working in cobalt Version 11 or do I need a later release?

Thanks.

Here is a snippet of the function in src/cobalt/dom/eme/media_key_session.cc
void MediaKeySession::OnSessionUpdateRequestGenerated(
    VoidPromiseValue::Reference* promise_reference, scoped_array<uint8> message,
    int message_size) {
  MediaKeyMessageEventInit media_key_message_event_init;
  // 10.9.4. If a license request for the requested license type can be
  //         generated based on the sanitized init data:
  // 10.9.4.1. Let message be a license request for the requested license type
  //           generated based on the sanitized init data interpreted
  //           per initDataType.
  // Otherwise:
  // 10.9.4.1. Let message be the request that needs to be processed before
  //           a license request request for the requested license type can be
  //           generated based on the sanitized init data.
  media_key_message_event_init.set_message(new ArrayBuffer(
      NULL, ArrayBuffer::kFromHeap, message.Pass(), message_size));
  // 10.9.4.2. Let message type reflect the type of message, either
  //           "license-request" or "individualization-request".
  //
  // TODO: Introduce message type parameter to |SbDrmSessionUpdateRequestFunc|
  //       and stop pretending that all messages are license requests.
  media_key_message_event_init.set_message_type(
      kMediaKeyMessageTypeLicenseRequest);

...
}

Maksym Motornyy

unread,
Mar 16, 2018, 10:30:17 PM3/16/18
to David Liu, cobalt-dev
I believe youtube.com/tv supports individualization, and YouTube's EME tests don't. Even though "individualization-request" is disguised as "license-request" in Cobalt, youtube.com/tv will still know how to handle individualization. So yes, it is my belief that Cobalt 11 properly supports individualization and there are production platforms that perform provisioning in the way I described.

Let me confirm this on Monday and get back to you. In the meanwhile, try contacting your YouTube account manager and confirm the format of individualization messages that you are supposed to send. Please note that Cobalt team doesn't maintain YouTube player.

Maksym Motornyy

unread,
Mar 22, 2018, 7:53:12 PM3/22/18
to David Liu, cobalt-dev
Hi David,

I apologize for misinforming you earlier. Apparently, app-assisted individualization is not supported by YouTube Player yet. I'm planning to work with them in coming weeks to address this issue and potentially make it work in Cobalt 11 as I described in the previous email. It could happen that update to Cobalt 16+ will be needed for this feature to work.

In the meanwhile I recommend you to perform individualization on your own. I do not recommend to use Cobalt as HTTP client library linked from your Starboard implementation, it'll create cyclic dependency and will make it harder to rebase your port to newer versions of Cobalt in the future.

Let me know if you have more questions.

Sincerely,
Maksym Motornyy.
Reply all
Reply to author
Forward
0 new messages