> And that’s the end of the story: the converters work, they’re passing through type 1 contents, and there’s nothing the movie studios can do about it. It’s all good.
Actually, they can... yank Lattice's license and/or keys for selling a chip that does things prohibited by the standard. That would render a ton of legitimate devices useless, but that also wasn't a problem when the HDCP v1 keys of a bunch of software BD/HDDVD players got yanked after their keys were dumped...
How would this work in practice if the device is never online and never updated with a list of acceptable device keys? Would it be applied at the encryption side to make keys that do not work with the offending key?
The device used in the original blog post is an Amazon streaming box, playing back video from Amazon's streaming service. So that device absolutely can be updated with new revocation lists.
For Blu-Ray players, discs contain updated revocation lists and players are required to store the most recent list. So any time you buy a new movie, you update that list. The delivery mechanism for this list is actually way more insidious than just having a file on the disc that players need to copy. There's actually a whole virtual machine in every Blu-Ray player, called BD+.
You see, if you were to just decrypt AACS[0] video data on a commercial Blu-Ray, you'd actually get a corrupted data stream, because you need to also run the BD+ program to get the fixup tables to unscramble the decrypted data. BD+ also adds facilities for the BD+ program to authenticate the player, inspect the state of the player software, and even run native code to update your player. If you don't provide the correct data[1] to the BD+ program, you don't get your fixup table, so every licensed Blu-Ray player implements BD+ such that all the inspection and update functionality works as intended.
[0] AACS is the DRM scheme that encrypts Blu-Ray disc data. It's HDCP's fraternal twin.
[1] Much of which is cryptographically signed and verifiable by the BD+ program
There is a provision that works using new content which could instruct the player to add certain keys to a revocation list. So if you buy a new Blu-ray and play it your player can be longer work with that key.
These systems are so thoroughly broken though that as far as I know this has never been used and the protection is more of a legal one.
again, it's the player that is blocking the key, which has been updated via a network connection that the user allowed to happen. If this is an inline device that is air gapped and doesn't even have a mechanism for updating the keys, how would this device ever be affected by its key being rejected?
Updates to the player can come with content. For streaming content, the provider can make streaming contingent on an updated firmware/application package that bans the hdcp keys. For disc based content, new discs can include key revocation.
That said, HDCP downgrading for compatibility is or at least was in the spec, so there's no justification to revoke the keys for the device discussed in the article.
right, but if you have a valid and current version of the player that decodes, say something like an app on an AppleTV 4K that pushes the video signal via HDMI, and inline box to bypass HDCP would not be affected by any key revocation what so ever. So again, how does this inline box get affected at all by any key revocation? After all, that's the subject of the TFA which we seem to have strayed a bit too far from the conversation with your hypothetical
An app on Apple TV may be valid and current today, but if it's playing streaming media, it may not be valid and current to get streaming content tommorow. Updates to the app or Apple TV firmware could include revocations such that tomorrow's required version will not authenticate with your inline device.
What do you mean by ‘a player that decodes an app on an AppleTV’?
If your AppleTV is running an app that is playing media, that app is the player. And that app will add the new keys, that it finds in the media it is playing, to its revocation list so that app can no longer play any protected media to the blocked device. It will refuse to communicate with the inline box because the key used by the box is now on the revocation list.
And there probably is some mechanism that causes this to apply systemwide, either because the encryption and list management is in some dedicated chip or because the list is shared systemwide.
Thanks. This is the part that I was missing. So the Netflix/Prime/Hulu app receives the updated listed of revoked keys. When it sees that the device it is communicating with has a revoked key, it will refuse to play/launch/however it fails. At that point, it could even be put on Apple's shoulders that the AppleTV unit shouldn't even connect to that device and not be the app developers???
I read the previous poster's comment as saying the revocation of the key would be embedded in newer content, and if the device is compliant it would revoke its own key when it encountered the newer content.
Actually, they can... yank Lattice's license and/or keys for selling a chip that does things prohibited by the standard. That would render a ton of legitimate devices useless, but that also wasn't a problem when the HDCP v1 keys of a bunch of software BD/HDDVD players got yanked after their keys were dumped...