W3C home > Mailing lists > Public > www-tag@w3.org > March 2014

Re: Some comments on the draft TAG EME paper

From: Henri Sivonen <hsivonen@hsivonen.fi>
Date: Tue, 4 Mar 2014 12:07:35 +0200
Message-ID: <CANXqsRLwmUGp7+CVBuYu-++PHndCO4nirrxPi+rYsCbcteh50Q@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: www-tag <www-tag@w3.org>
On Fri, Feb 28, 2014 at 5:56 PM, Mark Watson <watsonm@netflix.com> wrote:
> Existing solutions based on software obfuscation bundle decrypt and decode
> within the obfuscated code.

I'd expect a JS-based solution to do the same (and, therefore, not use
Web Crypto).

> Additionally, the technology available for
> obfuscation of compiled code is much more advanced than for Javascript.
> There is a long way to go before we could get to a solution that is both
> performant and robust.

UltraViolet refers would-be player vendors to Arxan (and Arxan
advertises itself with the logos of the UltraViolet-approved DRMs at
http://www.arxan.com/solutions/content-protection/ ), so presumably
Arxan can deliver sufficient obscurity. Arxan seems to have solutions
for x86_64, x86, ARM, Java and .Net at least. If they are able to
deliver sufficient obscurity with those instruction set targets, I
don't see a technical reason why they couldn't deliver sufficient
obscurity using asm.js as the instruction set, considering that asm.js
closer to x86 and ARM than Java and .Net and Arxan appears to be able
to obfuscate even Java and .Net (though, granted, nothing says that
the UltraViolet reference extends to the Java and .Net products).

Presumably, whatever Arxan does stays within practical performance
targets. Is there still breathing room to lose SIMD and then take a
1.5x slowdown from asm.js?

> The reason pre-provisioned keys are useful on such devices has more to do
> with the complexity of the supply-chain for those devices which dilutes the
> value of the attestation provided by the CDM (i.e. that attestation is
> restricted to CDM properties).

What attestation is needed beyond attestation of the CDM properties
(which presumably includes attestation of the output pipeline when
feasible)? Your proposal attests the device identity, so it seems to
me that in a non-Tivoized case it would attest even less about the
characteristics of software than attesting something about the CDM.

Henri Sivonen
Received on Tuesday, 4 March 2014 10:08:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:01 UTC