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.
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.