SPEKEAPIv2 - Personnalisations et contraintes de la spécification DASH -IF - Spécification de l'échange de clés d'encapsulage et d'encodeur sécurisés API

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

SPEKEAPIv2 - Personnalisations et contraintes de la spécification DASH -IF

La spécification DASH Industry Forum CPIX 2.3 prend en charge un certain nombre de cas d'utilisation et de topologies. La spécification SPEKE API v2.0 définit à la fois un CPIX profil et un API pourCPIX. Afin d'atteindre ces deux objectifs, il respecte le CPIX cahier des charges avec les personnalisations et contraintes suivantes :

CPIXProfil
  • SPEKE suit le flux de travail Encryptor Consumer.

  • Pour les clés de contenu chiffrées, les restrictions suivantes SPEKE s'appliquent :

    • SPEKEne prend pas en charge la vérification de signature numérique (XMLDSIG) pour les charges utiles de demande ou de réponse.

    • SPEKEnécessite des certificats RSA basés sur 2048.

  • SPEKEne tire parti que d'un sous-ensemble de CPIX fonctionnalités :

    • SPEKE omet la fonctionnalité UpdateHistoryItemList. Si la liste est présente dans la réponse, l'SPEKEignore.

    • SPEKEomet la fonctionnalité de touche root/feuille. Si l'ContentKey@dependsOnKeyattribut est présent dans la réponse, il l'SPEKEignore.

    • SPEKEomet l'BitrateFilterélément et l'VideoFilter@wcgattribut. Si ces éléments ou attributs sont présents dans la CPIX charge utile, l'SPEKEignore.

  • Seuls les éléments ou attributs référencés comme « pris en charge » sur la page des composants de charge utile standard ou sur la page du contrat de chiffrement peuvent être utilisés dans les CPIX documents échangés avec la SPEKE version 2.

  • Lorsqu'ils sont inclus dans une CPIX demande par le crypteur, tous les éléments et attributs doivent porter une valeur valide dans la CPIX réponse du fournisseur de clés. Dans le cas contraire, le crypteur doit s'arrêter et générer une erreur.

  • SPEKEprend en charge la rotation des touches avec KeyPeriodFilter des éléments. SPEKEutilise uniquement le ContentKeyPeriod@index pour suivre la période clé.

  • Pour HLS la signalisation, plusieurs DRMSystem.HLSSignalingData éléments doivent être utilisés : un avec une valeur d'DRMSystem.HLSSignalingData@playlistattribut « media » et un autre avec une valeur d'DRMSystem.HLSSignalingData@playlistattribut « master ».

  • Lors de la demande de clés, le chiffreur peut utiliser l'attribut facultatif @explicitIV sur l'élément ContentKey. Le fournisseur de clés peut répondre avec un vecteur d'initialisation à l'aide de @explicitIV, même si l'attribut n'est pas inclus dans la requête.

  • Le chiffreur crée l'identifiant de clé (KID), qui reste le même quels que soient l'ID de contenu et la durée d'utilisation des clés. Le fournisseur de clés inclut KID dans sa réponse au document de demande.

  • Le crypteur doit inclure une valeur pour l'CPIX@contentIdattribut. Lorsqu'il reçoit une valeur vide pour cet attribut, le fournisseur de clés renvoie une erreur avec la description « Missing CPIX @ contentId ». CPIX@contentIdla valeur ne peut pas être remplacée par le fournisseur de clés.

    CPIX@idla valeur, si elle n'est pas nulle, doit être ignorée par le fournisseur de clés.

  • Le crypteur doit inclure une valeur pour l'CPIX@versionattribut. Lorsqu'il reçoit une valeur vide pour cet attribut, le fournisseur de clés renvoie une erreur avec la description « Missing CPIX @version ». Lors de la réception d'une demande avec une version non prise en charge, la description de l'erreur renvoyée par le fournisseur de clés doit être « Unsupported @version »CPIX.

    CPIX@versionla valeur ne peut pas être remplacée par le fournisseur de clés.

  • Le crypteur doit inclure une valeur pour l'ContentKey@commonEncryptionSchemeattribut pour chaque clé demandée. Lorsqu'il reçoit une valeur vide pour cet attribut, le fournisseur de clés renvoie une erreur avec la description « Missing ContentKey @ commonEncryptionScheme for KID id ».

    Un CPIX document unique ne peut pas mélanger plusieurs valeurs pour différents ContentKey@commonEncryptionScheme attributs. À la réception d'une telle combinaison, le fournisseur de clés renvoie une erreur avec la description « commonEncryptionScheme  Combinaison ContentKey @ non conforme ».

    Les ContentKey@commonEncryptionScheme valeurs ne sont pas toutes compatibles avec toutes les DRM technologies. À la réception d'une telle combinaison, le fournisseur de clés doit renvoyer une erreur avec la description « ContentKey @ commonEncryptionScheme non compatible avec DRMSystem id ».

    ContentKey@commonEncryptionSchemela valeur ne peut pas être remplacée par le fournisseur de clés.

  • Lors de la réception de valeurs différentes pour DRMSystem@PSSH XML <pssh> un élément DRMSystem.ContentProtectionData interne dans le corps de la CPIX réponse, le crypteur doit s'arrêter et générer une erreur.

API pour CPIX
  • Le fournisseur de clés doit inclure une valeur pour l'en-tête de X-Speke-User-Agent HTTP réponse.

  • Un SPEKE crypteur conforme agit en tant que client et envoie les POST opérations au point de terminaison du fournisseur de clés.

  • Le crypteur doit inclure une valeur pour l'en-tête de la X-Speke-Version HTTP demande, avec la SPEKE version utilisée avec la demande, formulée sous MajorVersion la forme. MinorVersion, comme « 2.0 » pour la SPEKE version 2.0. Si le fournisseur de clés ne prend pas en charge la SPEKE version utilisée par le crypteur pour la demande en cours, il doit renvoyer une erreur avec la description « SPEKE Version non prise en charge » et ne pas essayer de traiter le CPIX document de son mieux.

    La valeur X-Speke-Version d'en-tête définie par le crypteur ne peut pas être modifiée par le fournisseur de clés en réponse à la demande.

  • Lorsqu'il reçoit des erreurs dans le corps de la réponse, le crypteur doit générer une erreur et ne pas réessayer la demande avec un versionnage SPEKE v1.0.

    Si le fournisseur de clés ne renvoie pas d'erreur mais ne renvoie pas un CPIX document contenant les informations obligatoires, le crypteur doit s'arrêter et générer une erreur.

Le tableau suivant récapitule les messages standard qui doivent être renvoyés par le fournisseur de clés dans le corps du message. Le code de HTTP réponse en cas d'erreur doit être un 4XX ou un 5XX, jamais un 200. Le code d'erreur 422 peut être utilisé pour toutes les erreurs liées àSPEKE/CPIX.

Cas d'erreur Message d’erreur

CPIX@ n'contentId est pas défini

CPIX@ manquant contentId

CPIX@version n'est pas défini

CPIX@version manquant

CPIX@version n'est pas pris en charge

@version non pris en charge CPIX

ContentKey@ n'commonEncryptionScheme est pas défini

ContentKey@ manquant commonEncryptionScheme pour KID id (où id est égal à la valeur ContentKey @kid)

Plusieurs commonEncryptionScheme valeurs ContentKey @ utilisées dans un seul CPIX document

commonEncryptionScheme Combinaison ContentKey @ non conforme

ContentKey@ n'commonEncryptionScheme est pas compatible avec DRM la technologie

ContentKey@ commonEncryptionScheme n'est pas compatible avec DRMSystem id (où id est égal à systemId la valeur DRMSystem @)

La valeur d'en-tête X-Speke-Version n'est pas une version prise en charge SPEKE

Version non prise en charge SPEKE

Le contrat de cryptage est mal formé

Contrat de chiffrement mal formé

Le contrat de chiffrement contredit les contraintes liées aux niveaux DRM de sécurité

CPIXLe contrat de chiffrement demandé n'est pas pris en charge

Le contrat de chiffrement n'inclut VideoFilter aucun AudioFilter élément

Contrat CPIX de chiffrement manquant