Re: Some comments on the draft TAG EME paper

Sent from my iPhone

> On Mar 4, 2014, at 2:07 AM, Henri Sivonen <hsivonen@hsivonen.fi> wrote:
>
>> 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?

Maybe. One issue might be the relative ease with which you could then
access the decoded frames in Javascript.

Anyway, whether the above is feasible doesn't really have any impact
on EME: EME wouldn't show up at all in the above solution.

>
>> 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.

The WebCrypto pre-provisioned keys approach would be useful on devices
like TVs and not so useful on desktop browsers. We've found this
approach to be successful on such devices at meeting our security
goals. The detailed security goals / threat analysis etc. is not my
area but it is related to security goals associated with our service
(as outlined in the use-case in WebCrypto) as well as goals associated
with the content.

...Mark




>
> --
> Henri Sivonen
> hsivonen@hsivonen.fi
> https://hsivonen.fi/

Received on Tuesday, 4 March 2014 15:14:08 UTC