Kernel support for HDCP

Posted Dec 9, 2017 13:32 UTC (Sat) by emunson (subscriber, #44357)
In reply to: Kernel support for HDCP by Otus
Parent article: Kernel support for HDCP

TPM attestation, this is one of the primary use cases of it. Through the TPM userspace can verify the boot chain from firmware* up.

*Caveats apply about trusting firmware, etc

Kernel support for HDCP

Posted Dec 9, 2017 20:28 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (7 responses)

No it can't - userspace has no way of knowing whether it's talking to a real TPM, and you can modify userspace so it thinks it is even if there's no TPM present at all.

Kernel support for HDCP

Posted Dec 10, 2017 3:27 UTC (Sun) by emunson (subscriber, #44357) [Link] (2 responses)

Then I am at a loss for how this will be useful in kernel. Vendors can sell locked down devices like chromecast, etc. But they are likely already carrying this sort of thing.

Kernel support for HDCP

Posted Dec 11, 2017 11:53 UTC (Mon) by matthias (subscriber, #94967) [Link]

Vendors need to ship one less out-of-tree patch. The advantages are the usual: no added maintenance efforts to port the patch when internal kernel structures change. As these changes are done by the Kernel community for in-tree code.

Kernel support for HDCP

Posted Dec 12, 2017 12:20 UTC (Tue) by farnz (subscriber, #17727) [Link]

I've encountered A/V gear that will only handle 48 kHz, 16 bit stereo PCM or lower quality audio without HDCP - it simply outputs silence if you give it anything else. Without this change, Linux is limited to low quality audio; with it, it can send bitstream audio to that device (Dolby Digital, DTS and friends), or it can send anything up to 192 kHz 8 channel 24 bit PCM and have it heard.

So, that's one gain - better interoperability with buggy gear.

Kernel support for HDCP

Posted Dec 11, 2017 13:45 UTC (Mon) by mageta (subscriber, #89696) [Link] (3 responses)

That is not true.

TPM designed a way for this: EK certificates. The EK private portion is saved on the TPM, the public part is signed on a certificate by a third party and proves that the key-pair belongs to a real TPM. If the DRM software would verify this, then it'll be hard for you to "fake" a TPM in software, w/o also convincing the signing party that your software TPM is "real".

At least that is my somewhat outdated understanding (last time I did something with TPM was 3 years ago).

Kernel support for HDCP

Posted Dec 11, 2017 19:37 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (2 responses)

How can the DRM software verify it? You can just patch out the check.

Kernel support for HDCP

Posted Dec 11, 2017 21:43 UTC (Mon) by mageta (subscriber, #89696) [Link] (1 responses)

I am not an expert in tamper proof/resistant software. From the top of my head I know that even commodity hardware now a days have stuff like Intel TXT + TPM, that would allow to preprogram a TPM with accepted program states (hashes of ELF binaries or something) and then let you proof this via signatures to the 3. party, before that 3. party is gonna let you have whatever content/access you wanna have.

Anyway. I am by no means an expert in making tamper proof/resistant software. I just knew that for the one case you mentioned, there was a solution. How to build that into a closed complete stack is too much for my limited knowledge.

Kernel support for HDCP

Posted Dec 11, 2017 21:59 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

Yes, you can perform remote attestation (although that's easily circumvented by simply using a second TPM), but there's no practical mechanism to deploy that in the real world.