Skip to main content

Axinom Key Service

The Key Service provides the encryption keys (Content Keys) to a packager to encrypt the media assets during the preparation stage.

For integration with 3rd party Packaging/Encryption software, it supports a variety of protocols for the exchange of generated keys. The currently supported products/protocols are:

The Key Service is a multi-tenant managed service, operated by Axinom. The Key Service provides two APIs:

Key Service exposing two APIs: Key Acquisition API and Management API

Key Acquisition API​

The Key Acquisition API is the API which provides the encryption keys - the main purpose of the Key Service.

It supports the following protocols/clients:

Read more: Key Acquisition API.

Management API​

The Management API allows to control several aspects of the tenant, such as:

  • Key Seeds
  • Content Keys
  • Import/Export of the Keys and Key Seeds
  • Logs

Read more: Key Service Management API.

Main Use Case​

The purpose of the Key Service is to provide Content Keys (encryption keys) upon request. The request can be made by a Packager/Encryption Engine or by another component, such as Content Management System, which then uses the keys to supply them to a Packager/Encryption Engine.

Key Service - Main Use Case

This scenario is very straightforward. However, there are a couple of requirements for the Key Service which make the solution more complicated:

  • Keys Synchronization - if the Key Service generates a Content Key used for encrypting a video, the corresponding License Service shall be able to reproduce the same Content Key for this video, so that the player can play the video
  • Multiple Keys - for some scenarios, it is important to deliver more than one key for a single request
  • Interoperability - make sure that the same Key Service can be used by different clients from different vendors
  • Security - make sure that the once generated key does not get compromised on its way to the consumer

Key Generation​

It would be very easy for the Key Service to generate fully random Content Keys. However, it would require non-trivial efforts to synchronize all the generated Content Keys with the License Service.

Instead, Axinom Key Service uses the so-called Key Seed Model (see What is DRM?).

Key Seed Model​

The Key Service holds one or more Key Seeds. A cryptographically strong Key Seed is generated when a new Tenant is created. Additional Key Seeds can be generated later using the Management API. When a new Content Key is needed, it is derived from the - secret - Key Seed and a - non-secret - Key ID (GUID) using a known function:

Content Key = f(Key Seed, Key ID)

The Key ID is either supplied by the Client or generated by the Key Service itself (random GUID) depending on the scenario.

If you would like to have full control over the used Key Seeds, you can import your own values using the Management API.

If you let the Key Service generate Key Seeds for you, but you need the Key Seeds value in your License Service, you can export the Key Seeds as an encrypted PKSC package using the Management API and import it to your License Service.

One of the Key Seeds is always the default one. The first generated Key Seed is automatically the default. But you can set any of the Key Seeds as default and at any point in time. The default Key Seed is used when no Key Seed is explicitly referenced.

Axinom Key Service uses the Key Seed Model as the default one for generating the keys.

Random Keys Model​

In this model, every key is just a cryptographically secure random number. As there is no way to "re-calculate" the key value later, every randomly generated content key shall be passed to the License Service individually.

With Axinom Key Service, it is possible to generate a random key using POST /ContentKeys without specifying a Key Seed ID in the Management API.

Keys Delivery Format/CPIX​

The requirements of interoperability between the Key Service and its Clients, such as Packagers, Encryption Engines, CMS, and the requirement of security suggest the usage of industry standards for the keys delivery format. Luckily, such a standard exists: Content Protection Information Exchange Format (CPIX), published by DASH Industry Forum (https://dashif-documents.azurewebsites.net/Cpix/master/Cpix.html).

A CPIX document contains keys and DRM information used for encrypting and protecting content and can be used for exchanging this information among entities needing it in many possibly different workflows for preparing, for example, DASH or HLS content. The CPIX document itself can be encrypted, signed and authenticated so that its receivers can be sure that its confidentiality, source, and integrity are also protected.

Most endpoints of the Key Acquisition API use CPIX for keys delivery.

CPIX is a sophisticated XML-format suitable for various scenarios and capable of embracing different information about the keys, DRM systems, and the usage rules. However, in its simplest form, a CPIX can be just a collection of keys, including their IDs and values.

Simple CPIX document
<?xml version="1.0" encoding="utf-8"?>
<CPIX xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:dashif:org:cpix" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:enc="http://www.w3.org/2001/04/xmlenc#" xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc">
	<ContentKeyList>
		<ContentKey kid="1294b959-9d75-5de2-bbf0-fdca3fa5eab8" explicitIV="ez6RSem1PE2CdoSC9jXosg==">
			<Data>
				<pskc:Secret>
					<pskc:PlainValue>MDEyMzQ1Njc4OWFiY2RlZg==</pskc:PlainValue>
				</pskc:Secret>
			</Data>
		</ContentKey>
		<ContentKey kid="2294b959-9d75-5de2-bbf0-fdca3fa5eab8" explicitIV="afqsAFfz6EqfrlsKa45yVA==">
			<Data>
				<pskc:Secret>
					<pskc:PlainValue>ZmVkY2JhOTg3NjU0MzIxMA==</pskc:PlainValue>
				</pskc:Secret>
			</Data>
		</ContentKey>
	</ContentKeyList>
    ...
</CPIX>

CPIX was published first in 2015 and has seen since that several versions (1.0, 2.0, 2.1, 2.2, 2.3). CPIX 2.3 is dated September 2020.

CPIX uses identifiers (GUIDs) assigned by DASH IF to each DRM technology. The following IDs are relevant for Axinom DRM:

DRM systems identifiers as defined by DASH-IF (https://dashif.org/identifiers/content_protection/)

DRM TechnologyIdentifier (System ID)
Widevineedef8ba9-79d6-4ace-a3c8-27dcd51d21ed
FairPlay94ce86fb-07ff-4f43-adb8-93d2fa968ca2
PlayReady9a04f079-9840-4286-ab92-e65be0885f95

Keys Delivery Protocols​

Having CPIX as a standardized keys delivery format is a big step towards interoperability and security. But there is still a lot of variety in how the different clients request the keys and how they use the many possibilities offered by CPIX.

Unlike CPIX, there is no single keys delivery protocol dominating the market. The two popular protocols are:

Axinom Key Service supports both protocols. It also support proprietary protocols used by:

  • Harmonic
  • Anevia
note

It is also possible to generate a key (or multiple) using the Management API (POST /ContentKeys) and then export it (them) as a single CPIX document (POST /Export/ContentKeys).

The Client can choose any of the supported protocols by connecting to a specific endpoint of the Key Acquisition API.