IPMX: Implementing HDCP with 'open-standards' for AVoIP

HDCP has been shrouded in mystery from the start – remember when everyone searched online to find out how it worked? and, intentionally, found very little? Now the IPMX folks are detailing the HDCP ‘how to do it’ in an Open Standard. Doesn’t publishing an ‘open standard’ derail any obfuscation?
IPMX: Implementing HDCP with 'open-standards' for AVoIP
Like

Share this post

Choose a social network to share with.

This is a representation of how your post may appear on social media. The actual post will vary between social networks

We all love to hate HDCP. It’s the protocol that ‘gets in the way of playing real-time media’ in AV systems. Its role is to protect the rights of the content owners (primarily Hollywood) when the media is outside secure storage. 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 which work together to secure the link.

The new challenges

AVoIP creates some new challenges – protecting 4k60 content as it streams across network connections, including potentially large numbers of simultaneous, yet changing, endpoints. A very different mission to its original brief: protecting FHD content distributed across point-to-point, circuit-switched connections — via connectors like DVI, HDMI, DisplayPort, and across cables and matrices.

HDCP v2.3, the latest incarnation, is not backwardly compatible with the original HDCP versions because packet-switched, multicast, network traffic is just not the same as circuit-switched connections. The protection challenges are different.

As version 2.x was developed, several parameters were left as ‘alternative options’. One of the aspects that was not ‘tied down’ for this multi-endpoint network environment was how to transfer HDCP messages (eg the encryption keys) between source and sinks. Consequently, all brands implement HDCP the same way for direct connections (e.g., HDMI to HDMI — from player to display), but for network connections ‘same brand at both ends’ frequently prevails - as different manufacturers favour and adopt particular options. In this context, choice isn't always a good thing.

IPMX rises to the challenge

Now IPMX is, by design, moving high quality video across networks — right up to and including uncompressed UHD60 (and potentially beyond!). But its interoperability aim is clearly not compatible with ‘same brand at both ends’.

Modern encryption techniques, such as those used in HDCP, are designed such that even if a 'bad actor' knows 'how' it is done, they can't undo it with the resources they have. And the designers of HDCP have done a good job in defining the elements that need to be exchanged between endpoints.

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 HDCP messages between IPMX transmitters and receivers.

The VSF recommendation, documented in TR-10-5, is compatible with the established HDCP v2.3 yet is lightweight enough to be incorporated into devices that may be varied, and probably limited in processing power (to keep their cost down). In other words, regardless of whether IPMX is implemented in those devices in ASIC, FPGA or software, HKEP is viable.

Additionally, it defines the ‘closing down’ process for a single HDCP session in that same multicast network environment. (Surprisingly perhaps, that too had some 'wiggle room' until now.)

Open standard yet wider protection

In conclusion, ‘open standard’ is a hallmark of IPMX, but that openness does not preclude securing content. For the first time, HKEP provides a defined way for devices from different brands to pass HDCP protected content between each other across an IP network — whatever bandwidth, or bandwidths, that might be.

And a ‘no option’ implementation surely increases the likelihood that it works first time without additional config being needed on site. And that's no bad thing either!

Please sign in

If you are a registered user on AVIXA Xchange, please sign in