[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 #79 from Henri Sivonen <hsivonen@hsivonen.fi> ---
(In reply to David Dorwin from comment #77)
> (In reply to Henri Sivonen from comment #70)
> I filed bug 26838 to address some of the vulnerabilities related to initData
> - specifically attacks #13-15.

Thanks.

Regarding earlier concerns about hardware CDMs projecting constant identifiers,
it's worth noting that it should be possible to have a hardware CDM with
identifier salting even without server-based individualization. That is,
addressing the persistent network-exposed identifier problem and the desire to
have a hardware CDM that doesn't need supporting individualization server
infrastructure after the secrets have been provisioned at the factory are not
mutually exclusive.

Here's how:

At the factory, instead of provisioning a per-device instance key (or key
pair), provision a per-device instance seed. The seed is just some number (e.g.
128 or 256) of randomly-generated (individually for each device-instance) bits
that are embedded in the hardware at the factory. That is, each device instance
ends up with a unique (except for extremely improbable collisions) seed that's
persistent through the lifetime of the device instance. Let's call this the
Device Seed.

Additionally, embed a signing key (RSA, (EC)DSA, Ed25519 or similar), let's
call this the Anonymity Set Private Key, into the hardware of multiple device
instances. A single Anonymity Set Private Key could be used for all device
instances of the same device model or even all device instances of different
device models that have the same hardware CDM implementation. The more device
instances have the same Anonymity Set Private Key, the better for user privacy,
but the more device instances have the same Anonymity Set Private Key, the
bigger a DRM robustness problem the compromise of that key becomes.

Embedding the Device Seed and the Anonymity Set Private Key is to be done in a
manner that makes it very difficult for these secrets to be extracted from the
hardware.

The public key corresponding to the Anonymity Set Private Key, let's call it
the Anonymity Set Public Key,is certified (signed) by the root of trust of the
DRM scheme (Key System) or by an intermediate key whose certification chains to
the root of trust of the DRM scheme. That is, certifications (key signing)
performed with the Anonymity Set Privace Key can be verified by Key Servers to
chain to the root of trust of the DRM scheme. Alternatively, each key server
could have a collection of all the different Anonymity Set Public Keys in
circulation to be able to check if a signature is made by a valid Anonymity Set
Public Key. This way, there is no need for chaining certifications (signatures)
to a root of trust. (Either way, there's a need to distribute information about
revoked keys to the key servers, so the system might as well distribute a list
of valid keys and omit the PKI hierarchy.)

At runtime, the hardware CDM receives a salt from the browser. Let's call this
the Salt. (The CDM doesn't need to know how the salt is generated, but a
reasonable policy is for the browser to randomly generate, and then remember
until the user asks it to be forgotten, a salt for each combination of
EME-using origin and the top-level origin.) The hardware CDM then combines the
Device Seed and the Salt to form a Salted Seed. The combination function needs
to be deterministic. It could be simply XOR (if the key system never lets the
browser see a value that could be reversed to the Salted Seed). It could also
be hashing the concatenation of the Salt and the Device Seed (or the Device
Seed and the Salt).

The hardware CDM then generates a key to be used for key acquisition. Let's
call this a Salted CDM Key. This key could be a secret symmetric key (e.g. AES
key), in which case it needs to be encrypted for the key server when sending it
over. (If the Salted CDM Key is encrypted for the key server, the browser
doesn't see it, so in the simplest case, the function for combining the Device
Seed and the Salt could be XOR and the Salted Seed could be Salted CDM Key
directly.) Alternatively, the Salted CDM Key could be an RSA public key (of the
generated key pair), in which case the Salted Seed would be used as the seed
for a CSPRNG used in RSA key generation. Alternatively, the Salted Seed could
be converted to an elliptic curve point using Elligator and the Salted CDM Key
could be an elliptic-curve Diffie–Hellman public key (of the generated key
pair). Or the Salted CDM Key could be derived from the Salted Seed using some
other deterministic mechanism.

The CDM then signs the Salted CDM Key using the Anonymity Set Private Key. This
signature is sent to the key server so that when the CDM performs key
acquisition advertising the Salted CDM Key to the key server, the key server
can convince itself that the Salted CDM Key belongs to a CDM that meets the
applicable robustness and compliance rules (since it possesses a Anonymity Set
Private Key whose corresponding Anonymity Set Public Key the key server
considers valid). The content keys are sent by the key server to the CDM by
using encryption that involved the Salted CDM Key (encrypted using the Salted
CDM Key if it is a symmetric key or an RSA public key or encrypted using a
shared secret derived from the Salted CDM Key if it is an (EC)DH public key,
etc.)

For maximum robustness, all the above should happen in tamper-resistent
hardware, but to trade off some robustness to gain ease of implementation, any
of the above steps could instead be performed in software (normal or inside a
TEE).

The notable characteritics are:
 1) The Salted CDM Key is bound to the hardware-bound Device Seed for
anti-cloneablity.
 2) If the Salt changes, a key server can't correlate the previous Salted CDM
Key and the new Salted CDM Key with each other beyond both belonging to devices
with the same Anonymity Set Private Key.
 3) The Anonymity Set Private Key enables on-device certification of Salted CDM
Keys, so there's no need for server-based individualization.

Inferring PlayReady design from the Defined Terms for Microsoft PlayReady
Compliance Rules and Robustness Rules, it seems to me this could be applied to
the existing PlayReady key system by making the Anonymity Set Private Key and
Anonymity Set Public Key correspond to Device Model Keys and by making the
Salted CDM Key correspond to the Device Public Key.

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

Received on Thursday, 18 September 2014 08:47:35 UTC