Authorization Binding
1. Principles
The SSP Account and Device Management service (ADM) let the operator Portal/SMS define the authorized devices of the subscriber account. These devices can then be authorized to access either IPTV/DVB or OTT content using either the Right management service (RMG) or by using Content Authorization Token (ContentAuthZ). To prevent security issue relating to the reuse or sharing of authorizations, SSP proposes various methods detailed below.
2. IPTV/DVB Authorizations Based on RMG
Any device requesting access to keys needed to decrypt IPTV/DVB contents needs to be uniquely authorized using the "caSN" field in the ADM. This field is the only one checked by the Product License management service (PLM) and comes from the device in a protected license request. This string field is formatted slightly differently depending on the device kind.
device | caSN format |
|---|---|
running the NOCS Connect client | STB_CA_SN field assigned by NAGRA as {32 bits as 10 decimal character converted as string padded with '0'} |
running the TKL Connect client | ID assigned by NAGRA as "0x"{128 bits as hexadecimal 16 characters string} |
running the SKL Connect client | ID assigned by the operator as read by the CCL on the device |
running the TVKeyCloud client | SoC UID assigned by TVKey as {64 bits as decimal converted as string without padding} |
3. OTT Authorizations Based on RMG
Any device requesting access to keys needed to decrypt OTT content authorized by RMG will perform a license request containing the following fields:
a DRM specific (PR, WV, FPS, Connect, ...) license request message a.k.a "DRM challenge". These message usually contains a unique identifier of the device assigned by the DRM system.
a SSP Device authentication token.
This message might include a "deviceId" field. In this case, this field needs to be equal to the "_id" field of a device authorized by the service provider in the ADM. This identifier is assigned by the service provider.
The token might include an "accountId" field. In this case, it is used to look up an authorized account with "_id" field with the same value in the ADM.
If the message does neither include "deviceId" not "accountId", the message will be rejected.
If the message includes both values, both will be checked and SSP will also check that the "deviceId" is really one of the authorized device of the "accountId" in the ADM.
In addition to the check of the various fields of the token, SSP performs automatically the deviceId binding operation.
4. OTT Authorizations Based on Content Authorization Token
Any device requesting access to keys needed to decrypt OTT content authorized by the Content authorization token will perform a license request containing the following fields:
a DRM specific (PR, WV, FPS, Connect, ...) license request message a.k.a "DRM challenge". These message usually contains a unique identifier of the device assigned by the DRM system.
a SSP Content authorization token. This message might include in the "device" structure:
nothing, in this case the token is not bound to any device and can be shared and reused as many times as wanted. This is perfect for demo but should never be used for production.
a "deviceUniqueId" field which needs to be equal to the unique identifier of the "DRM challenge". Using this field is the most secure way to avoid sharing (not reuse) of tokens but it supposes that the operator service creating the token has access to this "deviceUniqueId". W3C EME requirements prevents Javascript application to access such identifier.
a "deviceId" field which needs to be equal to a "_id" field of a device authorized by the service provider in the ADM. This identifier is assigned by the service provider.
An "accountId" field, if present, is currently ignored
Alternatively, the token can be defined as playable only once by using "jti" and "exp" fields.
In addition to the check of the various fields of the token, SSP performs automatically the (23.48) Authorization Binding#deviceId binding operation.
5. Device ID Binding
Each time a OTT license request is performed with a token containing a "deviceId" field, SSP will use the ADM service to validate that an authorized device record exists in ADM with an equal "_id" field.
Then, if such a device record has been found, SSP will check the "drmClientId" of this device record against the unique DRM identifier of the DRM challenge coming in the request.
On the first request, the "drmClientId" of the device record in the ADM will be empty, so the request will be accepted and SSP will set this value equal to the unique DRM identifier.
On any subsequent request, the request will be rejected if the "drmClientId" of the device record in the ADM if different from the unique DRM identifier coming from the DRM challenge in the request.
The deviceId binding behavior of SSP can be bypassed by simply not using the "deviceId" field in the token.
Device ID binding can be disabled via configuration:
For all devices: this can be used for a period of time after a device migration procedure.
For certain device models: sometimes devices are upgraded with a new DRM module that reports a different DRM device ID. In that case, the binding can be disabled to let SSP overwrite the old DRM device ID with the new value.
Please contact NAGRA Cloud Operations team or your NAGRA program manager to activate these options.