As we enter the start of IBC, there’s a variety of new developments from BuyDRM now coming to market. As part of this rollout, we wanted to share a significant update on how BuyDRM views and supports CPIX within the KeyOS multi-DRM platform. In this blog we will cover:
- What is CPIX?
- How Are Operators Using It?
- What Are The Security Risks in Today’s CPIX specifications?
- Introducing BuyDRM’s New KeyOS CPIX Specification v1.1.
What is CPIX?
CPIX is a DASH IF specification designed to enable operators to securely acquire DRM content encryption keys from DRM Platform operators in a standardized fashion. The specification was originally born out of the DRM Working Group which was later changed to the Content Protection Group.
At the time, every DRM company in the business, including BuyDRM had their own proprietary encryption key APIs and were widely deployed with them for nearly ten years with great effect. CAS companies on the other hand lacked these features and multi-DRM products but wanted to lead an effort to make a standard so they could easily enter the market. The specification itself is extremely thorough as well as complex and represents the DRM industry’s first wave attempt to create standards in a very non-standard business.
From a historical standpoint, BuyDRM opposed the concept of CPIX because it diminished the value of all of our existing encryption key API partner integrations (nearly 55) and gave new entrants into the marketplace (CAS Companies) the ability to quickly jump the shark and enter the market. We also felt it was inappropriate for other segments of the industry to dictate how we operate our APis as though that would be acceptable in the CDN or processing or encoding or player businesses which clearly it wouldn’t be.
That being said, we are supporters of CPIX today and have numerous publicly known CPIX integrations in place. As this blog post will show, we believe CPIX is a specification that needs more critical review from a security standpoint to be viable long-term in the OTT industry.
How Are Operators Using CPIX?
As a general specification available to the public here, the CPIX specification is available to anyone who can get on the Internet. On top of that, numerous encoding, packaging and server companies have also implemented their own version of the CPIX spec such that there are reportedly already 15 CPIX variants in motion at a variety of vendors of these encoding, packaging and server products. CPIX was supposed to unify and standardize one method for all encoders, packagers and servers to acquire encryption keys from DRM platforms. “One integration. One Standardized DRM content encryption key exchange.”
The reality of today’s landscape is that CPIX created more fragmentation in the marketplace than existed before. Previously we had 15-20 DRM vendor-specific encryption key APIs. Now we have 30-40. Now Server and Packaging and Encoding companies have tried to define to DRM companies how DRM should work. On the other hand, DRM vendors are still having to maintain and improve their legacy APIs while then attempting to implement variants of CPIX presented to them in parallel.
Encoding, packaging and server companies lack the fundamental “security chops” that security companies’ possess. Furthermore, they aren’t generally in the business of managing the secure and reliable transport of cryptographic information used in an end-to-end video workflow.
As an example, some CPIX adaptations rely on digest authentication which has numerous security concerns and criticisms and becomes problematic to use in a standard way to authenticate multiple parties which can participate in a content key information exchange.
All of this leads to considerable confusion, fragmentation, security myopathy and authentication and scale issues that need to be addressed for this industry to grow in parallel with the exploding OTT business.
What Are The Security Risks In Today’s CPIX Specifications?
In reviewing a variety of available CPIX specifications available in the marketplace from a range of well known encoding, cloud encoding, packaging and server companies, BuyDRM created a generalized summary of how and where these specifications are insecure. We then describe how the KeyOS CPIX Specification addresses these insecurities.
1. Lack of Content Key Encryption
- Many of the specs only use SSL for the content encryption key delivery which negates the entire concept of secure key exchange and compromises the entire workflow. Content Keys are critical strategic assets for Rights Holders and Content Providers. They have to be encrypted.
- BuyDRM encrypts Content Keys in our response to 3rd party ESP Partner platforms which our clients are using to encode, serve and play their content.
- The DASH IF CPIX Specification provides for a variety of security support including encrypting content encryption keys as described above as well as signing CPIX Documents using Document Keys and Certificates.
- BuyDRM requires the use of CPIX Document Signatures with Encoders, Packagers and Server certificates as well as the mutual client’s certificate when possible. As a result, we have the ability to authenticate and authorize specific partners and customers in order to quickly address potential security breaches or failures by temporarily disabling compromised partner until when the security issue will be resolved. This approach unlocks a more granular way to gain better access controls to the entire workflow
3. Lack of Multiple Keys for Audio, Video and SD/HD/4K Variants
- In today’s quickly evolving marketplace, the move from SD to 4K has accelerated. Microsoft and Google and Apple now allow for separate encryption keys for an audio track and its corresponding video track as well as separate encryption keys for each bitrate set. Many of the CPIX specs that BuyDRM reviewed, lacked this functionality.
- BuyDRM supports multiple keys for each bitrate in the same title and separate keys for the audio and video components of a title.
Introducing BuyDRM’s new KeyOS CPIX Specification v1.1.
BuyDRM has addressed three different areas of insecurity in existing specs with the KeyOS CPIX Specification v1.1 which will be available to all of our clients and ESP Partners beginning September 10th, 2019 via the KeyOS Console at www.keyos.com. In this specification you will find:
- Mandatory Content Key Encryption
- CPIX Document Signatures with multiple certificates from both partners and customers
- Support for multiple keys for the same title but with different Bitrates SD/HD/4K
- Support multiple authentication keys which means that partners and customers can rotate signing keys on a regular basis or generate new keys and immediately disable old ones in case they are compromised without interrupting the content protection workflow.
To address any confusion about our approach to CPIX please review these two key points:
BuyDRM absolutely has to ensure that content keys are only accessible inside a protected environment and cannot be acquired as plaintext by anyone. This is done using asymmetric cryptography where the private key is generated inside our ESP partner’s product (encoder/packager/server) and stays there. The content key thus can be only be decrypted by the ESP partner (encoder/packager/server).
BuyDRM needs to be able to authenticate the actual ESP partner which makes the content encryption key request on behalf of our customers’. BuyDRM also needs to be able to authenticate our customers with ease and in a secure fashion. This is critical in order to restrict the direct access to API and make sure that a request is authorized by the ESP partner. Using a single mechanism for both cases seems logical and as a result, document signature-based solutions are a reasonable solution.
For more information please visit www.buydrm.com where you pose questions and if you are a client or ESP Partner, access the KeyOS CPIX Specification v1.1 at www.keyos.com.
