Integrating Encoding with DRM

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.

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

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:

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
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

note

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