PSSH, PSSH box, and DRM signaling
If you use digital rights management (DRM) to protect video content, chances are that earlier or later you will run accross the term PSSH. It stands for Protection System Specific Headers and is a part of a so called DRM Signaling. In most cases, you don’t need to deal with PSSH directly, but in case you want to learn more about the topic, this article provides useful starting points.
When a video content is protected with DRM, the content is encrypted and metadata is added to the content. The process of including such metadata is referred to as DRM Signaling.
PSSH is a standardized container that holds metadata specific to the protection system employed for securing digital content. Hence PSSH is a part of DRM signaling.
PSSH DOES NOT containt the enryption key itself (it’s a secret), but it contains the necessary information about encryption, such as the key ID, the encryption scheme, and other information that is needed to obtain the key from a license server.
PSSH is ultimately defined in "ISO/IEC 23001-7:2023 MPEG systems technologies — Part 7: Common encryption in ISO base media file format files" (see below).
When a packager applies DRM protection to a video, it encrypts the content but it also adds some metadata to the content, usually in the form of a container called PSSH Box. There is a separate PSSH box for each DRM system used to protect the video (i.e., one video can contain multiple PSSH boxes - one per DRM system).
PSSH Box contains DRM system-specific PSSH Data. For example, for PlayReady, the PSSH Data is the PlayReady Header, defined here: https://learn.microsoft.com/en-us/playready/specifications/playready-header-specification.
Packagers usually do not generate encryption keys themselves, but request them from a secure Key Service. When a packager requests a key from a Key Service, it also received a PSSH box for the DRM system used to protect the video. The Key Service generates the key and the PSSH Box and returns them to the packager.
How exactly the PSSH box is returned, is defined by the respective Key Acquisition Protocol, such as AWS SPEKE or Widevine Common Encryption.
When a player plays the content, it detects that the content is encrypted and reads the respective PSSH box. The player then uses the information in the PSSH box to obtain the key from a license server.
PSSH box is a binary structure, so it’s not easy to read it.
Axinom offers a set of free tools that can parse the PSSH box and show the contents in a more readable way.
PSSH Box Decoder (https://tools.axinom.com/decoders/PsshBox) parses the PSSH box and shows the contents.
PSSH Data Decoder (https://tools.axinom.com/decoders/PsshData) parses DRM system-specific PSSH data and shows its content.
|To use the tools you have to register at https://portal.axinom.com.
In this chapter we cover deeper technical details on PSSH box and PSSH data.
The format for PSSH Box is DRM system-specific.
For PlayReady and Widevine, the PSSH Box format is essentially the same. The only differences are:
The system ID depending on the DRM system
The format of the nested PSSH Data
For FairPlay, the DRM signalling is usually either the full
#EXT-X-KEY tag that can be inserted to an HLS manifest or the URI attribute of that tag.
(This depends on the Key Acquisition Protocol used to acquire the key.)
The data contained there is basically the Key ID and an optional initialization vector (IV).
The following IDs are reserved for specific DRM systems (see also DRM Systems):
|Identifier (System ID)
The format for PSSH Data is DRM system-specific.
PSSH Data is the PlayReady Header, defined in the PlayReady Header Specification.
<WRMHEADER xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader" version="18.104.22.168">
<KID ALGID="AESCBC" VALUE="PV1LM/VEVk+kEOB8qqcWDg=="></KID>
<KID ALGID="AESCBC" VALUE="tuhDoKUN7EyxDPtMRNmhyA=="></KID>
Widevine’s PSSH Data full specification is not public.
Some pieces of it can be found in open sources, such as the Shaka Packager Git repository.
More detailed version of the definition is available to Widevine partners (such as Axinom), but even this definition is not complete.
FairPlay has no known public PSSH Data specification.
The PSSHs are first analyzed both by the player and (in a browser) by the media framework (MSE/EME). Usual workflow is that MSE/EME is given some content, it finds it’s encrypted and then automatically reads the PSSH from the fMP4 files and passes it on to player code, where player should then take further action.
Then, a CDM received PSSH as a part if "InitData". It possibly parses it and adds it to the license request, so the license service can also take a necessary action.
|Recommended workflow nowadays is though that PSSH should only be in manifest and not in fMP4 files. And with that, players should themselves be proactive and read it from the manifest and utilize the info later for license request generation. Players can go even that far to generate a full PSSH box themselves, based on the key ID and encryption scheme, which are also available elsewhere.
There are two versions of PSSH box: Version 0 and Version 1.
While the Version 0 is the most commonly used, the Version 1 is the "recommended" one, but it doesn’t have wider adoption yet at the time of writing.
In Version 1, the PSSH box with System ID `1077efec-c0b2-4d02-ace3-3c1e52e2fb4b" is called the "common PSSH box" - it’s a step towards standadization for all DRM systems.
This is defined in EME spec "cenc" Initialization Data Format.
The Version 0 is different only in that it doesn’t contain the
KID list compared to what is shown in the above link.
Axinom Key Service generates PSSH boxes for the respective DRM systems and returns according to the used key acquisition protocol. If you use Axinom tools, such as SPEKE and Widevine Common Encryption, you can see the returned PSSH boxes.
Axinom Encoding, when DRM is used, generates the necessary PSSH boxes and includes them to the packaged content. Note: you can’t pass a ready PSSH box to Axinom Encoding.
Axinom License Service receives PSSH boxes as a part of the license request and processes them according to the rules of the DRM system used.
https://www.iso.org/obp/ui/#iso:std:iso-iec:23001:-7:ed-4:v1:en - ISO/IEC. ISO/IEC 23001-7:2023, Information technology — MPEG systems technologies — Part 7: Common encryption in ISO base media file format files.
https://dashif.org/docs/IOP-Guidelines/DASH-IF-IOP-Part6-v5.0.0.pdf - DASH-IF Interoperability Points; Part 6: Content Protection
https://learn.microsoft.com/en-us/playready/specifications/mpeg-dash-playready - Microsoft / DASH Content Protection using Microsoft PlayReady
https://learn.microsoft.com/en-us/playready/specifications/playready-header-specification - PlayReady Header Specification.