Anevia

Axinom Key Service supports a direct integration with Anevia NEA-DVR, a cloud DVR solution that enables the viewers to record live TV shows.

The integration endpoint is /Anevia of the Key Acquisition API.

Functionality

The Client requests one or more content keys. The Key Service generates the necessary keys using the Key Seed model and returns the keys with additional DRM-specific metadata where needed.

Authorization

This endpoint requires an authorization header - the same as described under the Key Service Management API.

Request/Response Format

Request

The Client provides the input parameters in a JSON data structure, in the so-called CPIX Configuration. CPIX Configuration shall be supplied in base64-encoded form. Individual properties of this data structure control the respective aspects of the generated CPIX document.

{
	"ContentKeyIds":
	[
		"00000000-0000-0000-0000-111111111111",
		"00000000-0000-0000-0000-222222222222"
	],
	"DrmSystemIds":
	[
		"94ce86fb-07ff-4f43-adb8-93d2fa968ca2",
		"9a04f079-9840-4286-ab92-e65be0885f95",
		"edef8ba9-79d6-4ace-a3c8-27dcd51d21ed"
	],
	"ContentKeyUsageRules":
	[
		{
			"KeyId": "00000000-0000-0000-0000-111111111111",
			"AudioFilters":
			[
				{
				}
			]
		},
		{
			"KeyId": "00000000-0000-0000-0000-222222222222",
			"VideoFilters":
			[
				{
					"minPixels": 0, "maxPixels": 2073600
				}
			]
		}
	]
}

The table below explains the elements of the request JSON.

Element	Description
ContentKeyIds	The list of the Key IDs for which the Keys shall be generated. Key ID is a GUID.
DrmSystemIds	Requested DRM types, for which the PSSH boxes will be delivered. The IDs are as defined by DASH-IF. Axinom Key Service supports FairPlay, PlayReady, and Widevine (listed in the example above in this order).
ContentKeyUsageRules	Content key usage rules for each key. It’s a pass-through which will be set in CPIX and returned to the Client.

For more information on valid combinations of Content Key Usage Rules and how Anevia NEA-DVR processes Content Key Usage Rules, see the document NEA-DVR-SW - CPIX back-end by Anevia (Please contact Anevia in order to get the document).

Response

The response is a CPIX document.

Example CPIX document returned by the '/Anevia' endpoint

<?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="00000000-0000-0000-0000-111111111111" explicitIV="Ue7qBIMJFkSgNQdeBEEMnQ==">
      <Data>
        <pskc:Secret>
          <pskc:PlainValue>mLE9R9fKrFiE8KB5OiVPYA==</pskc:PlainValue>
        </pskc:Secret>
      </Data>
    </ContentKey>
    <ContentKey kid="00000000-0000-0000-0000-222222222222" explicitIV="v4qKp01BqkyqerPOS+nX0A==">
      <Data>
        <pskc:Secret>
          <pskc:PlainValue>VhpO1WowkZ5RQlOKnLtdow==</pskc:PlainValue>
        </pskc:Secret>
      </Data>
    </ContentKey>
  </ContentKeyList>
  <DRMSystemList>
    <DRMSystem systemId="94ce86fb-07ff-4f43-adb8-93d2fa968ca2" kid="00000000-0000-0000-0000-111111111111">
      <URIExtXKey>c2tkOi8vMDAwMDAwMDAtMDAwMC0wMDAwLTAwMDAtMTExMTExMTExMTExOjUxRUVFQTA0ODMwOTE2NDRBMDM1MDc1RTA0NDEwQzlE</URIExtXKey>
    </DRMSystem>
    <DRMSystem systemId="94ce86fb-07ff-4f43-adb8-93d2fa968ca2" kid="00000000-0000-0000-0000-222222222222">
      <URIExtXKey>c2tkOi8vMDAwMDAwMDAtMDAwMC0wMDAwLTAwMDAtMjIyMjIyMjIyMjIyOkJGOEE4QUE3NEQ0MUFBNENBQTdBQjNDRTRCRTlEN0Qw</URIExtXKey>
    </DRMSystem>
    <DRMSystem systemId="9a04f079-9840-4286-ab92-e65be0885f95" kid="00000000-0000-0000-0000-111111111111">
      <ContentProtectionData>PGNlbmM6cHNzaC...UGdBPTwvcHJvPg==</ContentProtectionData>
    </DRMSystem>
    <DRMSystem systemId="9a04f079-9840-4286-ab92-e65be0885f95" kid="00000000-0000-0000-0000-222222222222">
      <ContentProtectionData>PGNlbmM6cHNzaCB4...BUGdBPTwvcHJvPg==</ContentProtectionData>
    </DRMSystem>
    <DRMSystem systemId="edef8ba9-79d6-4ace-a3c8-27dcd51d21ed" kid="00000000-0000-0000-0000-111111111111">
      <ContentProtectionData>PGNlbmM6...QY2xac0c8L2NlbmM6cHNzaD4=</ContentProtectionData>
    </DRMSystem>
    <DRMSystem systemId="edef8ba9-79d6-4ace-a3c8-27dcd51d21ed" kid="00000000-0000-0000-0000-222222222222">
      <ContentProtectionData>PGNlbmM6c...L2NlbmM6cHNzaD4=</ContentProtectionData>
    </DRMSystem>
  </DRMSystemList>
  <ContentKeyUsageRuleList>
    <ContentKeyUsageRule kid="00000000-0000-0000-0000-111111111111">
      <AudioFilter />
    </ContentKeyUsageRule>
    <ContentKeyUsageRule kid="00000000-0000-0000-0000-222222222222">
      <VideoFilter minPixels="0" maxPixels="2073600" />
    </ContentKeyUsageRule>
  </ContentKeyUsageRuleList>
</CPIX>

The table below describes the key elements of the response CPIX document.

Element	Description
ContentKeyList	A generated Key and an initialization vector (IV) for each Key ID.
DrmSystemList	Additional protection data for each requested DRM system and for each key
ContentKeyUsageRuleList	Content key usage rules, the same as in the request

Encryption Schemes

The Anevia endpoint always uses a default encryption scheme. It is "cenc" for Widevine and PlayReady and "cbcs" for FairPlay.

Fixed IV

When the fixedIv parameter is set to true, the returned IVs will be non-random and derived based on the Key IDs.

https://key-server-management.axprod.net/api/Anevia?fixedIv=true&id=base64data

Why is a fixed IV necessary for some scenarios?

While generating random IVs is generally recommended for security reasons, there are cases where it is necessary to encrypt the same content using exactly the same Key and IV pair. For example, when multiple encoders simultaneously process the same content and CDNs or caching mechanisms are involved, having consistent encryption parameters ensures that the output remains consistent across all encoders.