Content Key Token (Kc)

See also

1. About

The page defines the format of the Content Key token generated by service providers to let SSP create a DRM license with a specific key. When used, this token needs to be sent along with a (23.48) Content Authorization Token (ContentAuthZ).

Usage of Content Key token is optional. NAGRA recommends using the content key service (see Content License Mgt Service (CLM) for PurePlay MDRM documentation).

2. Security

Content Key token payload is encrypted using the encryption key included in the credentials identified by "kid" claim in the token's header.

Content Key token header and payload are signed using the signing key included in the credentials identified by "kid" claim in the token's header. A portion of the message is encrypted with AES-128-CBC. Extra data remains unencrypted; the combination of both is authenticated by HMAC-SHA256. The algorithm used is described in https://tools.ietf.org/html/rfc7518 , section 5.2.

2.1. Diagram

3. Header

3.1. Schema

JSON

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "title": "Content Key Token Header Schema",
  "required": [
    "typ",
    "alg",
    "enc",
    "kid",
    "kcIds"
  ],
  "properties": {
    "typ": {
      "description": "JSON Web Token type",
      "type": "string",
      "value": "JWT"
    },
    "alg": {
      "description": "Hashing algorithm used",
      "type": "string",
      "value": "dir"
    },
    "enc": {
      "description": "Encrypting algorithm used",
      "type": "string",
      "value": "A128CBC-HS256"
    },
    "kid": {
      "description": "Identifier of the credential used to sign the token",
      "type": "string"
    },
    "kcIds": {
      "description": "Identifier(s) as list of UUIDs of the key(s) used to encrypt the content",
      "type": "array",
      "minItems": 1,
      "items": {
        "$ref": "#/definitions/uuid"
      }
    }
  },
  "definitions": {
    "uuid": {
      "description": "128-bits universally unique identifier - UUIDs are documented as part of ISO/IEC 11578:1996. Example: '123e4567-e89b-12d3-a456-426655440000'",
      "type": "string",
      "pattern": "^[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}$"
    }
  }
}

3.2. Sample

JSON

{
  "typ": "JWT",
  "alg": "dir",
  "enc": "A128CBC-HS256",
  "kid": "263953",
  "kcIds": [
    "ffffffff-aaaa-bbbb-cccc-000000000500",
    "ffffffff-aaaa-bbbb-cccc-000000000501"
  ]
}

4. Payload

4.1. Schema

JSON

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "title": "Content Key Token Payload Schema",
  "required": [
    "typ",
    "ver",
    "keys"
  ],
  "properties": {
    "typ": {
      "description": "CLM content key token type",
      "type": "string",
      "value": "Kc"
    },
    "ver": {
      "description": "CLM content key token version",
      "type": "string",
      "value": "1.0"
    },
    "keys": {
      "description": "List of content keys",
      "type": "array",
      "minItems": 1,
      "items": {
        "description": "Any symmetric key, with its identifier",
        "required": [
          "kcId",
          "value"
        ],
        "properties": {
          "kcId": {
            "description": "Key identifier as a UUID (128-bits universally unique identifier - UUIDs are documented as part of ISO/IEC 11578:1996). Example: '123e4567-e89b-12d3-a456-426655440000'",
            "type": "string",
            "pattern": "^[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}$"
          },
          "value": {
            "description": "Key value, base64 encoded. Byte array as a base64 string according to http://www.ietf.org/rfc/rfc4648.txt chapter 4",
            "type": "string",
            "pattern": "^[a-zA-Z0-9+/]+={0,2}$"
          }
        }
      }
    }
  }
}

4.2. Sample

JSON

{
  "typ": "Kc",
  "ver": "1.0",
  "keys": [
    {
      "kcId": "ffffffff-aaaa-bbbb-cccc-000000000500",
      "value": "/u0AAN6tAADerwAAvu8AAw=="
    },
    {
      "kcId": "ffffffff-aaaa-bbbb-cccc-000000000501",
      "value": "AAECAwQFBgcICQoLDAoODw=="
    }
  ]
}

5. Signature

In order to build signature, token's header and payload are signed:

Signing key used corresponds to the SSP tenant's credential identified by "kid" claim from the token's header.
Algorithm used is HMAC-SHA256 as described in https://tools.ietf.org/html/rfc7518, section 5.2.