This is my approximation of how it works. A work, say a movie, is encrypted using the public portion of a session key pair created especially for the purpose.
Many copies of the private session key are also stored alongside the movie. But, they are each encrypted with the public key of every registered player who has not had their key revoked.
Initially it may be one key per manufacturer, but this may expand to a key per device model, then to an additional serial number per individual device or even a key per device, as used in encrypted TV.
Players are expected to maintain a secret data path for as far as possible between the disc and the intended user's eyes and ears. They will have to convince the scheme operators of this before they are granted a key. If they subsequently disclose this key, the scheme operators will just drop their key from future media releases and their player will then be unable to decrypt and play those releases, just to give them a good incentive to keep the keys secret.
Players may become available after the original media was released. They will likely play old media through reserved or date based keys, not originally allocated to a specific manufacturer, reserved for this purpose on the original media.
I imagine for last-resort update of the cryptographic keys, that players will read smartcards distributed by their manufacturer. Otherwise they can get keys transmitted by any available network, e.g. radio (TV/GSM) broadcast.
The decoder chipset in the media player may run through the following questions.
At the display or speaker ends a different story.
Can existing computers be downgraded to provide restrictions? Well, BIOS firmware can be changed, which will alter processor microcode before control is passed to the OS on every startup.
The purpose of this microcode is to prevent the BIOS from being read by any program or updated by anything other than a signed patch. Microcode is the internal CISC to RISC translation found on computer processors.
It can also provide a way to run encrypted OS binaries. Executable Instructions will be decrypted by the microcode/BIOS using a key unlocked by an electronic token "certificate of authenticity" provided by the OS distributor, which may be a smartcard or dongle.
This token is installed in the computer chassis and is interrogated on startup and by curious OS subroutine library files.
OS providers now just compile their program, and then encrypt it.
Once the inner workings of the OS have been made secret, even from disassembly, it might choose to participate in multimedia restrictions.
Peripherals can often more easily be altered for restrictions as they require the participation of their BIOS in order to change it. Once a change requires a signature for subsequent changes, the hardware could be considered controlled. It may then participate in movie restriction by minimising the chance of the host reading out its private keys stored in the ROMs.
The secrecy ultimately depends on the difficulty of access of the private keys. They will be stored as close as possible to the signing math unit, which these days, means on the same chip and as close as possible to deter microprobing, which is the filing off of the top of a chip to expose the silicon and pressing needles on the key roms. This also means that the chip will avoid serialising the private key internally.
Can an electrical connection ever really prevent a smartcard from getting glitched? Opto-isolating this may help that state of affairs. We might try making the smartcard surface into a tiny solar panel with a LED to provide the comms back channel. Even if the terminal tries to saturate the device with an electrical, magnetic or electromagnetic (photonic, etc) field it should not be able to make the card surrender the key. An adversary may even attempt to gently file away the plastic covering the smartcard's solar panel. The smartcard must then erase the private key before the adversary gets to the silicon substrate for a microprobing attack.