[Bug 27272] New: Normatively require distinctive identifiers to be encrypted on the Key System level when EME is not being restricted to secure origins only

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

            Bug ID: 27272
           Summary: Normatively require distinctive identifiers to be
                    encrypted on the Key System level when EME is not
                    being restricted to secure origins only
           Product: HTML WG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Encrypted Media Extensions
          Assignee: adrianba@microsoft.com
          Reporter: hsivonen@hsivonen.fi
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org
        Depends on: 27268

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.

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

Received on Friday, 7 November 2014 12:25:48 UTC