DRM Protection Phase

Table of Contents

Content Key Handling
- Direct Mode
  - CPIX Details
- Managed Mode
Multiple Keys Support
Encryption Schemes
Revision History

The Encoding Service protects the videos to be used with the major DRM technologies, such as Widevine, PlayReady, and FairPlay. All DRM technologies use the AES encryption with a 128-bit Content Key.

Figure 1. Interactions between the Encoding Service and other systems during the DRM Protection Phase

Content Key Handling

There are two scenarios for handling the Content Key:

Direct mode: The Client provides the key to the Encoding Service as a part of the job description. The Client can use any Key Service or even generate the key themselves.
Managed mode: The Client provides credentials for a Key Service and the Encoding Service acquires the necessary key itself. For this scenario, the Encoding Service supports the Axinom Key Service (see the Key Service Management API article).

Direct Mode

The diagram below visualizes the interactions of the parties involved in the Content Key(s) exchange in the direct mode:

Figure 2. Interactions in the Direct Mode

Use the Direct Mode in the following cases:

You would like to have fine-tuned control over the key generation process
You decide on the Key ID and store it before the encoding process starts
You use a Key Service other than the Axinom Key Service

The generated key and related information is passed to the Encoding Service as a part of the ContentProcessing section, e.g.:

{
    "ContentProcessing": {
        ...
        "DrmProtection": "Base64Key",
        "KeyId": "ad0c138e-2591-45c5-94ea-80b3697c6da9",
        "ContentKey": "YWQwYzEzOGUyNTkxNDVjNQ=="
        ...
    }
}

The Key ID is a GUID which uniquely identifies the Content Key and helps the key assignment to the respective video/stream. Once generated, the Content Key shall be secured well. There are several possibilities how to include the Content Key in the job description, signalized by the value of the "DrmProtection" element:

DrmProtection Value Description Comment

DrmProtection Value	Description	Comment
`Base64Key`	`ContentKey` is included as a plain text, just base64-encoded	This is the least secure option. It is recommended to use it only for development or test scenarios, never in production.
`CertificateEncryptedBase64Key`	`ContentKey` is encrypted with the Encoding Service' certificate.	See Credentials Protection on how to use the certificate to encrypt the passed strings.
`Base64Cpix`	`ContentKey` is included into a CPIX document, base64-encoded.	CPIX is a standardized way of protecting the keys exchange. This is the preferred way to pass the keys to the Encoding Service. Check Key Service documentation for more details and examples of CPIX. Axinom Key Service can provide the keys already as CPIX-documents, so you don’t have to worry about these details if you are using Axinom Key Service.

Base64Key

ContentKey is included as a plain text, just base64-encoded

This is the least secure option. It is recommended to use it only for development or test scenarios, never in production.

CertificateEncryptedBase64Key

ContentKey is encrypted with the Encoding Service' certificate.

See Credentials Protection on how to use the certificate to encrypt the passed strings.

Base64Cpix

ContentKey is included into a CPIX document, base64-encoded.

CPIX is a standardized way of protecting the keys exchange. This is the preferred way to pass the keys to the Encoding Service. Check Key Service documentation for more details and examples of CPIX. Axinom Key Service can provide the keys already as CPIX-documents, so you don’t have to worry about these details if you are using Axinom Key Service.

You are encouraged to apply Credentials Protection to the ContentKey, i.e. to use the DRM Protection mode "CertificateEncryptedBase64Key" instead of "Base64Key". The same example as above for the Encoding Service (West Europe) would look like:

{
    "ContentProcessing": {
        ...
        "DrmProtection": "CertificateEncryptedBase64Key",
        "CredentialsProtection": "Encrypted",
        "KeyId": "ad0c138e-2591-45c5-94ea-80b3697c6da9",
        "ContentKey": "Ug27o+9Vzr1DU/TNYz0tqiWS6Vt+3d0S1Od0BE51gPPtf5EzMqG+JEP8tTrdV/z2crtJwhPqKeOPkh1ng3qi3U1O2WZ4YJmdiKloDtOYd0hWEB4B84up7u/pLTRZ9WCVyY+2N1SpfhIJ7qaVEDr1ATns44jMWpqmVi0hJbm+j30aKrGiK3hlrNckEdUQxvqnGFgRgIrH08FJioQB1yW6iRwhc05qburSJF2n8uw3kZqhAoVB5j4K3s0YulzCU4dLdeqlOiVfhdwFy0RbWIBYJ7UaKeTMCGvhjUM/8HcXuDYNAnph28GONG2K+cRc6ks+M2vorW6WdliNViIlyDZYLoiYvCZjsTkx9CwdlNCix4PmS9Bd8T+3ukjw6mzh4CDvbDzBCnj4bmOECN8yTcqRz07THqWtYZnAhEkS7jjBRXTxF49Lh9h5Eb4ablvb8gV0DCt6zpZLwNiF2qMpZjADPDJtsHByJ5XJSKyjXH6G83rmdzrjEHtUV8w1iIYqozwl"
        ...
    }
}

Tip	You can use the Credentials Protection Tool to encrypt credentials.

CPIX Details

A single CPIX document can contain multiple keys. If this is the case, different keys are used to protect different streams. Please provide at least as many keys as there are different quality groups in the respective video, max. 5 (Audio, SD, HD, UHD1, UHD2). The EncodingFinished event contains the full list of streams with the exact assignment of the keys (Key ID) and initialization vectors (IV) to the streams.

Warning

CPIX element cpix:ContentKeyUsageRuleList for assigning the keys to the tracks is not supported.

Other limitations:

No support for per-key custom Widevine/Playready PSSH data
No support for per-key custom HLS media playlist data, EXT-X-KEY for HLS
A single IV is used for all keys.

Managed Mode

The diagram below visualizes the interactions of the parties involved in the Content Key(s) exchange in the managed mode:

Figure 3. Interactions in the Managed Mode

Use the Managed Mode in the following cases:

You use Axinom Key Service.
You don’t want to deal with the details of the key generation and exchange.
You don’t want to "touch" the keys at all (additional level of security).

The signalling of the managed mode occurs with setting the "DrmProtection" element to "Managed" and adding a "DrmManaged" element (all the UUIDs below are just sample values, you need to replace them with your configuration values):

{
    "ContentProcessing": {
        "OutputFormat" : ["Dash", "Hls"],
        "DrmProtection": "Managed",
        "DrmManaged": {
            "ApiUrl": "https://key-server-management.axprod.net/api/",
            "TenantId": "123e4567-e89b-12d3-a456-426614174000",
            "ManagementKey": "123e4567-e89b-12d3-a456-426614174000", // Use the encrypted Key service Management key value
            "KeySeed": "123e4567-e89b-12d3-a456-426614174000", // Use the encrypted Key Seed ID
            "Thumbprints": "Axinom Key Server Production,Axinom Key Server Testing,AxinomKeyServerTesting", // Use the encrypted value
            "MultiKey": false,
            "Proxy": false,
            "KeysProtection": "Encrypted"
        }
    }
}

Note	You can use the Credentials Protection Tool to encrypt credentials.

The table below lists the elements used within the "DrmManaged" element.

Element Description Mandatory? Comments

Element	Description	Mandatory?	Comments
`ApiUrl`	Axinom Key Service API URL	Mandatory	You receive it as a part of Axinom DRM configuration.
`TenantId`	Axinom Key Service TenantId	Mandatory	You receive it as a part of Axinom DRM configuration.
`ManagementKey`	Axinom Key Service Management Key	Mandatory	You receive it as a part of Axinom DRM configuration.
`KeySeed`	Key Seed ID from which the keys shall be derived	Mandatory, if Proxy=False	Axinom Key Service supports multiple Key Seeds. You can see the Key Seed IDs in thef Axinom DRM configuration. In the proxy mode (`Proxy`=true), the Key Seed ID must not be set, as the Key Service Proxy has its own logic of selecting a Key Seed.
`Thumbprints`	Thumbprints of the Key Service certificates which Encoding should trust	Mandatory	Set always to: `"Axinom Key Server Production,Axinom Key Server Testing,AxinomKeyServerTesting"`
`MultiKey`	Multiple key support	Optional, default=false	See Multiple Keys Support below.
`Proxy`	Key Service proxy	Optional, default=false	Set to `"true"` if Key Service Proxy is used (you will also need to set the `ApiUrl` to point to the Key Service Proxy)
`KeysProtection`	If the secrets in the configuration are encrypted	Optional, default=false	If true, the fields `ManagementKey`, `KeySeed`, `Thumbprints` shall be encrypted as described under Credentials Protection

ApiUrl

Axinom Key Service API URL

Mandatory

You receive it as a part of Axinom DRM configuration.

TenantId

Axinom Key Service TenantId

Mandatory

You receive it as a part of Axinom DRM configuration.

ManagementKey

Axinom Key Service Management Key

Mandatory

You receive it as a part of Axinom DRM configuration.

KeySeed

Key Seed ID from which the keys shall be derived

Mandatory, if Proxy=False

Axinom Key Service supports multiple Key Seeds. You can see the Key Seed IDs in thef Axinom DRM configuration. In the proxy mode (Proxy=true), the Key Seed ID must not be set, as the Key Service Proxy has its own logic of selecting a Key Seed.

Thumbprints

Thumbprints of the Key Service certificates which Encoding should trust

Mandatory

Set always to: "Axinom Key Server Production,Axinom Key Server Testing,AxinomKeyServerTesting"

MultiKey

Multiple key support

Optional, default=false

See Multiple Keys Support below.

Proxy

Key Service proxy

Optional, default=false

Set to "true" if Key Service Proxy is used (you will also need to set the ApiUrl to point to the Key Service Proxy)

KeysProtection

If the secrets in the configuration are encrypted

Optional, default=false

If true, the fields ManagementKey, KeySeed, Thumbprints shall be encrypted as described under Credentials Protection

Warning

You are encouraged to apply Credentials Protection to the Key Service credentials (fields ManagementKey, KeySeed, Thumbprints). Encrypt the values and set "KeysProtection": "Encrypted". Eventhough we don’t recommend it, you can use the unencrypted Key Service credentials (fields ManagementKey, KeySeed, Thumbprints). In that case, you have to set "KeysProtection": "Unencrypted"

See Axinom Key Service documentation for further details on Key Service Proxy.

Multiple Keys Support

Following the industry’s best practices, the Encoding Service supports encrypting different streams with different Content Keys. This way, a License Service can assign different usage policies to different streams, depending on the video quality group.

To use multiple keys, you should provide more than one key to the Encoding Service. This is only possible if the keys are passed as a part of a CPIX-document. You can read more about CPIX under DRM documentation. In the direct mode, you can generate such a CPIX-document yourself (or acquire it from a Key Service). In the managed mode, you can set MultiKey=true, and the Encoding Service requests all the needed keys from the Axinom Key Service.

Currently available keys are assigned based on video quality groups. In addition, one key is assigned to all audio tracks. Note that the Axinom Encoding Service will request enough keys from Axinom Key Service to cover every quality group from this list:

Audio
SD
HD
UHD1
UHD2

Read more about the quality groups of streams under Encoding Billing.

Ideally, each video quality group is assigned a separate key. All video representations in the same quality group share the same key. In case there are less keys than quality groups, then higher quality groups are assigned separate keys and lower quality groups share a key. If the CPIX document provides at least two keys, then audio always gets a separate key while all video quality groups share a key.

The Encoding Service will use one key for all audio streams, and distribute the remaining keys among the bitrate groups. Bitrate groups are logical groupings of streams with a similar quality level.

The EncodingFinished event contains the full list of streams with the exact assignment of the keys (Key ID) and initialization vectors (IV) to the streams.

Note	Currently, the same IV is used for all streams. For CENC output, such as DASH, an 8-bytes IV is used, for CBCS - 16-bytes IV.

Encryption Schemes

Even though all the DRM technologies use AES as the encryption algorithm, there are different encryption schemes, which can make encrypted content incompatible with some of the technologies.

The Encoding Service uses the following encryption schemes:

Packaging	Encryption scheme
DASH	CENC
DashOnDemand	CENC
HLS	CBCS
CMAF	CBCS

Packaging

Encryption scheme

DASH

CENC

DashOnDemand

CENC

HLS

CBCS

CMAF

CBCS

Note	Today, we recommend to use CMAF and CBCS to prepare the content once and to use it with all major DRM technologies.

Revision History

The table below lists the document versions and any changes to them.

Version Date Description

Version	Date	Description
1.0	March 23, 2021	Initial version.
1.1	May 4, 2021	`ContentKey` example update.
1.2	May 18, 2021	Elements within the `"DrmManaged"` element listed as a table.
1.3	October 27, 2021	Better clarification on DRM options, incl. credentials protection. Possibility to supply a CPIX file with multiple keys in the Direct Mode

1.0

March 23, 2021

Initial version.

1.1

May 4, 2021

ContentKey example update.

1.2

May 18, 2021

Elements within the "DrmManaged" element listed as a table.

1.3

October 27, 2021

Better clarification on DRM options, incl. credentials protection.
Possibility to supply a CPIX file with multiple keys in the Direct Mode