Everyone in the AV community knows HDCP, the high-bandwidth digital content protection protocol. Love it or loathe it, HDCP is now part of everyday AV working lives. It was designed by Intel and adopted by Hollywood as the method by which valued content is secured, primarily to prevent piracy in a real-time environment. In other words, whilst content is being played, as opposed to whilst moving a file. The focus is on the transmission channel, providing protection as content passes from source to sink.
HDCP addresses this with three interlinked systems: Authentication, Encryption, Key Revocation
Simply put, HDCP only allows content to move to endpoints that are legitimate and authenticated HDCP receivers and then protects the content whilst in motion. This uses a system of encryption keys that work together to secure the link.
The original scope perceived the signal distribution as being point-to-point, circuit-switched connections—via connectors like DVI, HDMI, DisplayPort, and across cables and matrices.
AV is a Moving Landscape
All security systems are challenges for people who try to break them. Each of the three HDCP sub-systems, authentication, encryption, and revocation were targets. Devices that stripped the protection soon became available. A ‘master key’ that could not be revoked found its way into circulation. And thus, despite legal action, the original HDCP system was defeated—but nonetheless was still required for compliance.
The advent of increasing resolutions and the emergence of AV-over-IP raised both an additional challenge and an additional opportunity. UHD was the new value to be protected and there would now be a much larger number of endpoints involved, (i.e., multicast). Further, due to being transmitted via a network, the connections were now packet-switched, not a continuous connection.
HDCP evolved from v1 to v2, but this was not a backward-compatible step because the content transmission architecture was different. Several parameters were left as optional alternatives. One of the aspects that was not ‘tied down’ for this multi-endpoint network environment was how to transfer HDCP messages between source and sinks. The consequence is that for direct connections (e.g., HDMI to HDMI—from player to display) all brands do it the same way, but for network connections, it tends to be ‘same brand at both ends.’
Enter IPMX. IPMX is, by design, moving high-quality video—right up to and including uncompressed UHD60—across networks. But the ‘same brand at both ends’ is not compatible with its interoperability ethos. So, a consistent method for exchanging keys needed to be defined.
Most people think that the protection provided by encryption is reinforced by not revealing the method used. The ‘magic’ of modern encryption methods is that they know exactly how it is protected—even telling them how it is done, such as putting it in an open standard—and yet they still can’t decrypt it with the resources they have. The HDCP protocol itself addresses exactly that. Their method of using the keys is rigorous. To bring inter-brand HDCP to the IPMX multicast environment, the Video Services Forum (VSF) has made a significant contribution in proposing the HDCP Key Exchange Protocol (HKEP). This is a standardized approach, or ‘method in common’ of transferring the already defined messages between IPMX transmitters and receivers. Additionally, it defines the ‘closing down’ process for a single HDCP session in that same multicast network environment.
The methodology that VSF has recommended in TR-10-5, for use in IPMX, is compatible with everything that has been agreed to so far yet is lightweight enough to be incorporated into devices that may be varied, and probably limited in processing power (to keep their cost down). The extension to the already established HDCP specs covers the exchange of HDCP control messages over TCP/IP among NMOS-based transmitters and receivers. You can think of it as a preamble to the existing HDCP protocol v2.3 which prescribes how to transfer parameters, left optional by DCP, should be used in the IPMX environment.
