Improve streaming content security with SPEKE v2.0 and AWS Elemental MediaPackage

A quick history of CPIX and SPEKE

Until the publishing of the DASH-IF’s Content Protection Information Exchange Format (CPIX) specification in 2015, there was no standard payload format that encoders and packagers could leverage when requesting encryption keys from key servers. CPIX filled this gap by providing a high-level framework, based on XML, describing the streams to protect, the related encryption keys, and carrying the manifest signaling information.

While CPIX was a true industry innovation at that time, its applicability was also limited. It is a wide framework with multiple options to support for implementers, doesn’t include a standard API to carry the XML documents, and covered only the DASH use case at that time (not the HLS and Smooth Streaming ones).

AWS Elemental created the Secure Packager and Encoder Key Exchange (SPEKE) specification at the end of 2017, based on CPIX v2.0. SPEKE v1.0 implemented a CPIX extension, profile, and API. The CPIX extension adds custom XML namespaces to cover the HLS and MSS signaling use cases. The CPIX profile restricts the number of supported CPIX features to a specific scope, and the CPIX API covers both on-premises and cloud deployment topologies.

The industry saw the interest from customers for this unifying approach, with multiple DRM service providers quickly adopting SPEKE v1.0 together with the underlying CPIX v2.0 specification. Packager implementations also started appearing outside of the AWS Elemental portfolio.

Some of the specifications of SPEKE v1.0 have since been challenged. The extension of CPIX with a custom namespace created fragmentation in the industry, as DASH-IF was improving the CPIX specification by adding HLS and MSS support. Some of the restrictions carried by SPEKE in its CPIX profile, especially the required use of a single encryption key for all audio and video tracks, were also becoming problematic as vulnerable audio decoders could be used to extract content keys from the audio tracks and then used to decrypt the video tracks.

Finally, the SPEKE API didn’t allow to state the version of the CPIX specification used in a given transaction, making it difficult to guarantee backward and forward compatibility. In 2019 and 2020, AWS Elemental worked with the DASH-IF Content Protection Taskforce to enrich the CPIX specification with versioning, and with the SPEKE DRM partners to remove the limitations mentioned previously, with version 2.0 of the SPEKE specification.

SPEKE v2.0 benefits

AWS responded to the SPEKE v1.0 challenges users encountered, by retiring the CPIX extensions and allowing multiple encryption keys to protect different tracks in a flexible way.

With version 2.0, SPEKE is aligned on CPIX version 2.3 of the specification. The explicit cross versioning is ensured by the use of the new CPIX@version attribute in CPIX documents, and of the new X-Speke-Version HTTP header in SPEKE API calls. Both the packager and the key server know exactly which version of the documents and/or of the API is used, removing any ambiguity as regards to the XML structure used and the behavior of the components in the workflow.

The new standardized error messages and error management guidelines included in the SPEKE v2.0 specification facilitate debugging operations. The deprecation of the custom XML namespace brings the benefit of the latest features of CPIX v2.3, which was particularly important for the dual #EXT-X-KEY and #EXT-X-SESSION-KEY signaling in HLS playlists, and the signaling of AES scheme used in the key requests.

The support for multiple encryption keys is the other benefit introduced with SPEKE v2.0. The requested encryption keys can now be mapped to specific audio or video tracks, through the combined usage of the VideoFilter and AudioFilter elements, and of the ContentKeyUsageRule@intendedTrackType attribute. This mapping can be done based on the number of channels for the audio tracks, or on the resolution, frame rate, and HDR characteristics for the video tracks. It mitigates attacks on vulnerable audio decoders by using separate keys for audio and video tracks. It also enforces complex and stringent content protection requirements when separate encryption keys are required for SD/HD/4K/8K resolutions, high value HDR/HFR video tracks, or multichannel audio tracks.

SPEKE v2.0 in AWS Elemental MediaPackage

SPEKE v2.0 is already available in AWS Elemental MediaPackage for Live DASH endpoints – with Widevine and PlayReady support. Now, the equivalent Live CMAF implementation – with FairPlay, Widevine, and PlayReady support – is available alongside the new SPEKE v2 specification.

In both cases, the number of encryption keys that can be used is two: one for all the audio tracks, and one for all the video tracks. Since not all customers are CPIX experts, we enabled the definition of the encryption contract on CMAF and DASH endpoints through the choice of managed Video encryption and Audio encryption presets, in the API and AWS Management Console.

SPEKE configuration from the AWS Management Console for AWS Elemental MediaPackage

Upcoming features include additional encryption contracts, leveraging the capabilities offered by SPEKE v2.0 VideoFilter and AudioFilter elements support, and live key rotation. These upcoming features will be covered by the new SPEKE v2.0 Qualification Program that certifies our DRM partners’ implementations through extensive automated and manual tests. You can find the list of qualified implementations in the updated SPEKE v2.0 onboarding page.

More information about MediaPackage’s current DRM coverage in SPEKE v1.0 and SPEKE v2.0 is available on the Content encryption documentation page, and details about the SPEKE v2.0 configuration options are available on the Live CMAF and Live DASH pages as well as on the Live API page.

End-to-end SPEKE v2.0 workflow

If you operate your own key server infrastructure and want to develop your own SPEKE Server, you can self-validate your implementation with the SPEKE v2.0 Test Suite available in the updated SPEKE Reference Server framework GitHub repository.