Skip to main content
Skip table of contents

Authorisation and playback

Summary

Premium content is always protected by a content protection system to ensure that only the purchaser can consume the content. To allow the device to play back the protected content, a key must be delivered to the device so that it can unlock the content protection. Whilst the mechanism for encrypting content is widely known (usually a form of AES), the mechanism to protect the key is kept hidden.

Hardware security

Closed devices, such as set top boxes or home gateways, which contain software controlled by the service provider can contain specific hardware that is used to decipher the key provided by the content security system. In both cases they are provided by the Security solution vendor. This can be in the form of on-chip hardware, or on a smartcard. Because the mechanism to protect the key is hidden within the hardware circuit, it makes reverse engineering the mechanism extremely difficult.  

For broadcast networks using hardware secured devices, a CAS system such as the NAGRA anyCAST GUARD system can be used. These CAS systems push keys over broadcast streams to devices that are tuned to the stream. The delivery mechanism is either one-way or asynchronous, as the key is delivered over the broadcast network, rather than in response to a request. In this case, the key is delivered in response to a content purchase request or by the operator triggering it; there is no need for further interaction from the client application.

Software security

Some closed devices and all open devices (where the service provider cannot control the entire software stack or hardware) are protected by software security. You can sometimes use some form of partial hardware security with these devices (for example the NAGRA on-chip security), but because some of the mechanism exists within software that cannot be entirely hidden from a user, the mechanism is less secure than full hardware security. 

An open device decrypts the content key using software decryption. Because it is easier to reverse engineer software encryption, it is considered less secure than hardware encryption.

The key delivery request must be authorised by a third party. This authorisation means checking that the subscriber has purchased the content and that the purchase is still valid. For key delivery mechanisms that can also signal the key validity period, this usually means retrieving this subscription validity period and delivering it with the key.

The OpenTV Platform supports multiple content protection systems. 

Direct versus indirect license acquisition

There are two modes of license delivery: direct and indirect. When using direct mode, the application or client middleware requests the license directly from the DRM service. This service is then responsible for requesting authorisation from the relevant authorisation portal, for example SDP. Because direct mode is DRM specific, its integration is not covered here.

In indirect mode, the application or middleware requests the license from the portal or DRM proxy, which first authorises the request before requesting the license from the DRM service. Indirect mode provides an advantage to the DRM system in that it does not have to serve any unauthorised requests, however, it does mean that the portal has to keep a connection open with the client while it waits for the license to be generated by the DRM service (which can take a while because encryption is used).

Data model

For the License Specification data model, see License Specification reference.

Use cases

Content authorisation and playback are available through the NMPExtendedService and the LicenseService.

STB get license

Request a license from a configured license server for a previously-purchased content item. This retrieves a license for a given content and a device using the context data.

CODE
GET http://<server>:<port>/hue-gateway/gateway/http/js/LicenseService/getLicenseWithContext?context=<context>&licenseSpec=<spec>
Parameters
Name
Type
Description
contextContext data modelA Context object with information about the client requesting the license (including a decrypted challengeId if required). 
licenseSpecLicense Specification data modelA LicenseSpecification containing information that identifies the item to be licensed.

LicenseResponse type is returned. This contains a String which is a license string suitable for passing to the client's cryptography subsystem.

STB get license with challenge

Retrieves a license for the currently signed-on Set Top Box to view the specified Asset, with challenge authentication.

CODE
GET http://<server>:<port>/hue-gateway/gateway/http/js/LicenseService/getLicenseWithChallengeAuthentication?contentId=<id>&challengeID=<id>
Parameters
Name
Type
Description
contentIDStringThe unique identifier for the Asset as used by the license server. In NAGRA PRM deployments, this is the casId of the Asset.
challengeIDStringThe decrypted challenge.

The license is returned by the license server, encoded as a character string.

Open device get license indirect

Allows building a OpenTV Player license by transforming an existing local content message (LCM).

CODE
GET http://<server>:<port>/hue-gateway/gateway/http/js/NmpExtendedService/getEntitlements?playerVersion=<version>&playerType=<type>&opaqueData=<data>&contentId=<id>
Parameters
Name
Type
Description
playerVersionStringMedia Player Version.
playerTypeStringMedia Player type.
opaqueDataStringThe Opaque data from player.
contentIdStringLocal Content Message data.

This API returns the EntitlementsResponse with the entitlements data.

See also

The full SDP API documentation.

The MDRM API documentation (if MDRM is used).

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.