This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27272 - Normatively require distinctive identifiers to be encrypted on the Key System level when EME is not being restricted to secure origins only
Summary: Normatively require distinctive identifiers to be encrypted on the Key System...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: David Dorwin
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard: Privacy
Keywords:
Depends on: 27268
Blocks:
  Show dependency tree / graph
 
Reported: 2014-11-07 12:25 UTC by Henri Sivonen
Modified: 2014-12-02 01:34 UTC (History)
7 users (show)

See Also:

Attachments

Description Henri Sivonen 2014-11-07 12:25:47 UTC 
When the use of EME is not restricted to secure origins only (including ancestors; bug 27271), distinctive identifiers can be exposed eavesdroppers, which is bad for privacy. To at least hide distinctive identifiers from passive eavesdroppers and from active attackers who don't have a key server at their disposal, I think the spec should require Key System-level encryption when the secure origin restriction is not being enforced.

It is worth noting that Key System-level encryption is somewhat stronger requirement than an https requirement, because it does a bit more in terms of the budget/effort required for the attacker to become the recipient for whom data is encrypted. Obtaining an https certificate for an attacker-controlled domain is well within the capability of even very low-budget coffee shop attackers. Obtaining and operating key server requires more budget and effort.

On the other hand, https encryption is performed by the User Agent while Key System-level encryption is performed by the CDM. Thus, someone who treats the CDM as un-trusted is able to audit a User Agent to perform https encryption properly, but auditing the User Agent shows nothing about Key System-level encryption not having a covert channel disclosing data to eavesdroppers in addition to carrying data to the key server (i.e. some part of the random-looking supposedly encrypted data is actually something else).

I am not proposing a User Agent-level encryption wrapper for Key System messages, because it seems like an overkill to design such a thing in the interim (assuming that we'll get https eventually) and because designing such a system to use existing https PKI poses the problem that the browser doesn't know where the EME messages are going, so the browser couldn't figure out what to validate as a Common Name. (And a Key System-specific PKI is best handled by the Key System instead of making the User Agent aware of Key System-specific PKI.)

Note that the key server still gets to see the distinctive identifier(s). Bug 27269 makes the distinctive identifiers useless for tracking across sites and bug 27270 user-electively mitigates tracking across time on a given site by enabling point-wise discontinuities.

(Start proposed spec text for a *normative* section)

In the presence of distinctive identifiers in a Key System and in the absence of the User Agent restricting the use of the Key System (or the APIs defined in this specification as a whole) to secure origins, the distinctive identifiers that occur in Key System messages MUST be encrypted on the Key System-layer. Such Key System-level encryption is RECOMMENDED even when the Key System is restricted to secure origins only.

Note: This means, among other things, that signatures made with or certificates relating to device-specific or user-specific keys MUST be encrypted for the key server and encrypted messages from the key server to the CDM MUST NOT show recipient-unique ids (such as the id of the intended decryption key) on the outside of the encryption envelope.
Comment 1 Henri Sivonen 2014-11-07 12:38:43 UTC 
Oh, and the text should probably specify that messages to the key server MUST be encrypted with a key that the CDM can determine to belong to a key server for the relevant Key System and messages to the CDM MUST be encrypted with a key that the key server can determine to belong to a CDM for the relevant Key System.
Comment 2 Glenn Adams 2014-11-07 15:14:16 UTC 
I oppose adoption of this proposal due since it would dictate policy for the use of EME, which IMO is the prerogative of users of EME, and not the EME specification. In other words, I believe EME should restrict itself to defining mechanism, and not policy. If it is desirable to define a normative policy or set of policies that can be optionally adopted for standardized uses by some EME user, then such policy(ies) may be defined in a separate document and adopted (or not) by EME users as they see fit.
Comment 3 David Dorwin 2014-11-10 22:44:36 UTC 
(In reply to Henri Sivonen from comment #0)
> When the use of EME is not restricted to secure origins only (including
> ancestors; bug 27271), distinctive identifiers can be exposed eavesdroppers,
> which is bad for privacy. To at least hide distinctive identifiers from
> passive eavesdroppers and from active attackers who don't have a key server
> at their disposal, I think the spec should require Key System-level
> encryption when the secure origin restriction is not being enforced.

I want to highlight that the original case makes a case for strongly recommending (if not requiring) encryption even when requiring secure origins. We might want to update the summary to cover that.

Note that "encryption" alone is not a sufficient requirement. The encryption implementation must ensure that the ciphertext is not usable as a distinctive identifier.
> 
> It is worth noting that Key System-level encryption is somewhat stronger
> requirement than an https requirement, because it does a bit more in terms
> of the budget/effort required for the attacker to become the recipient for
> whom data is encrypted. Obtaining an https certificate for an
> attacker-controlled domain is well within the capability of even very
> low-budget coffee shop attackers. Obtaining and operating key server
> requires more budget and effort.

Another/An additional mitigation of such an attack is for the user agent to inform or warn users when such identifiers are exposed. User are unlikely to allow access to an identifier related to media, especially from an unknown domain, when browsing other sites. The warning is also a deterrent from launching such attacks (at least on user agents that surface the request). See bug 27165, though it is currently specific to unclearable identifiers.
> 
> On the other hand, https encryption is performed by the User Agent while Key
> System-level encryption is performed by the CDM. Thus, someone who treats
> the CDM as un-trusted is able to audit a User Agent to perform https
> encryption properly, but auditing the User Agent shows nothing about Key
> System-level encryption not having a covert channel disclosing data to
> eavesdroppers in addition to carrying data to the key server (i.e. some part
> of the random-looking supposedly encrypted data is actually something else).

This is one of the reasons enforcement of secure origins (bug 26332) is important regardless of CDM/key system mitigations.
Comment 4 David Dorwin 2014-12-02 01:34:44 UTC 
Implemented in https://github.com/w3c/encrypted-media/commit/b600fa8f58d8c808d024ab6217fe01a3b98e218d

I tried to include all the points from comment #0 and comment #1 to the best of my understanding along with the first two paragraphs in comment #3.