[Bug 26332] Applications should only use EME APIs on secure origins (e.g. HTTPS)

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332

--- Comment #48 from Henri Sivonen <hsivonen@hsivonen.fi> ---
Instead of using a term like "rogue" when different people might have a
different threshold of what behavior counts as "rogue", I think it would be
more productive to state which attacks specifically you'd like to defend
against.

Here are some attacks I can think of:

1) The user clears caches, cookies, etc., and changes the IP address after
having visited a particular site that uses EME. Then the user comes back to the
site. The site correlates this new visit with the previous visit using an
identifier exposed by the Key System.

2) The user visits site A and site B that both use the same CDM. Sites A and B
collude on the server-side to compare their notes of Key System-exposed
identifiers and correlate the visit to site A and to site B as coming from the
same user.

3) The user visits an EME-using site multiple times and a passive eavesdropper
on the network correlates these visits as coming from the same user by
observing a Key System-exposed identifier in the network traffic.

4) The user visits multiple sites that use the same CDM and a passive
eavesdropper on the network correlates these visits as coming from the same
user by observing a Key System-exposed identifier in the network traffic.

5) The user visits an EME-using site multiple times and/or visits multiple
same-CDM-using sites and an active attacker on the network injects additional
uses of the CDM into the site(s) such that the injected uses of the CDM speak
the Key System protocol with a server that the attacker controls in order for
the attacker to correlate these visits as coming from the same user by
observing a Key System-exposed identifier as decoded from the protocol by the
attacker-controlled implementation of the Key System protocol.

6) The user visits a non-EME-using site multiple times and/or visits multiple
non-EME-using sites and an active attacker on the network injects uses of the
CDM into the sites that otherwise wouldn't use EME such that the injected uses
of the CDM speak the Key System protocol with the server that the attacker
controls in order for the attacker to correlate these visits as coming from the
same user by observing the Key System-exposed identifier as decoded from the
protocol by the attacker-controlled implementation of the Key System protocol.

Which ones of these attacks is this bug about defending against? Are there
additional attacks that this bug is about? Which ones of these attacks are CDMs
deployed in IE, Chrome and Safari currently vulnerable to? What about the CDM
that Opera demoed for "devices"?

Salting the identifiers with browser-provided salt that the user can instruct
the browser to forget along with cookies addresses attack #1 and can
incidentally happen to foil attack #3 at some point in time.

Salting the identifiers with per-origin browser-provided salt addresses attacks
#2 and #4.

(Mozilla's announced plan includes salting with the characteristics described
in the two above paragraphs/sentences.)

The Key System protocol encrypting messages from the CDM to the key server such
that only the key server can decrypt identifiers and encrypting messages from
the key server to the CDM in such a way that the encrypted messages don't
reveal the identity of a unique-per-CDM-instance key with which they can be
decrypted addresses attacks #3 and #4. (The latter could be achieved by not
declaring any sort of key identity so that the only way to know if you have the
right key is to try decryption or by having an outer layer of encryption that
decrypts with the key that's common to a large number of CDM instances.)

Prompting the user to authorize the use of CDM on a per-site basis addresses
attack #6 if the user has a good  grasp of what capabilities site is supposed
to need and could address attacks #1 and #2 in cases where the CDM is only
invoked for tracking purposes and there isn't actually any media on the sites
that the user wants to play and the user has a good grasp of what capabilities
a site with no media that the user wants to play is supposed to need.

Restricting EME secure origins only would address attacks #5 and #6 and, if
mixed-content XHR and Web Sockets are blocked, attacks #3 and #4 as well.

As far as I can tell, the main reason against restricting EME to secure origins
only would be that it would make it harder for sites that don't already use
secure origins to migrate from NPAPI-based DRM to EME-based DRM. How serious is
this issue?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 21 August 2014 11:18:53 UTC