Encode your video content with the Encoding Service and protect it the major DRM technologies, such as Widevine, PlayReady, and FairPlay. Learn how Axinom DRM is integrated with encoding

DRM Protection Phase

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.

Encoding_ServiceKey_ServiceMessage_Publisheropt[Direct Mode]Get Key(s) from the job[Managed Mode]Get Key(s)Content Key(s)Allocate the keys to the streamsDRM ProtectionEncodingFinished (key allocation details)
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:

Interactions 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

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:

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 signaling 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",
            "KeySeed": "123e4567-e89b-12d3-a456-426614174000",
            "Thumbprints": "Axinom Key Server Production,Axinom Key Server Testing,AxinomKeyServerTesting",
            "MultiKey": false,
            "Proxy": false,
            "KeysProtection": "Unencrypted"
        }
    }
}

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

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

Warning
You are encouraged to apply Credentials Protection to the Key Service credentials (fields ManagementKey, KeySeed, Thumbprints). Encrypt the values and set "KeysProtection": "Encrypted". The example above uses unencrypted values only for illustration purposes and better readability.

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 on the Billing Model page.

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

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

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