View a markdown version of this page

SPEKE API v2.0 - Personnalisations et contraintes par rapport à la spécification DASH-IF - Spécification d'API Secure Packager and Encoder Key Exchange

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.

SPEKE API v2.0 - Personnalisations et contraintes par rapport à la spécification DASH-IF

La spécification CPIX 2.3 du DASH Industry Forum 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 profil CPIX et une API pour CPIX. Afin d'atteindre ces deux objectifs, il adhère à la spécification CPIX avec les personnalisations et les contraintes suivantes :

Profil CPIX
  • SPEKE suit le flux de travail d'Encryptor Consumer.

  • Pour les clés de contenu cryptées, SPEKE applique les restrictions suivantes :

    • SPEKE ne prend pas en charge la vérification des signatures numériques (XMLDSIG) pour les charges utiles de demande ou de réponse.

    • SPEKE nécessite 2048 certificats RSA-based .

  • SPEKE exploite uniquement un sous-ensemble de fonctionnalités CPIX :

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

    • SPEKE omet la fonctionnalité root/leaf clé. Si l'ContentKey@dependsOnKeyattribut est présent dans la réponse, SPEKE l'ignore.

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

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

  • Lorsqu'ils sont inclus dans une demande CPIX par le chiffreur, tous les éléments et attributs doivent porter une valeur valide dans la réponse CPIX du fournisseur de clés. Si ce n'est pas le cas, le chiffreur doit s'arrêter et renvoyer une erreur.

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

  • Pour la signalisation HLS, plusieurs DRMSystem.HLSSignalingData éléments doivent être utilisés : l'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 chiffreur doit inclure une valeur pour l'CPIX@contentIdattribut. Lors de la réception d'une valeur vide pour cet attribut, le fournisseur de clés doit renvoyer une erreur avec la description « Missing CPIX @contentId ». CPIX@contentIdLa valeur ne peut pas être modifiée par le fournisseur de clés.

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

  • Le chiffreur doit inclure une valeur pour l'CPIX@versionattribut. Lors de la réception d'une valeur vide pour cet attribut, le fournisseur de clés doit renvoyer 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 CPIX @version ».

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

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

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

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

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

  • Lors de la réception de valeurs différentes pour DRMSystem@PSSH <pssh> un élément DRMSystem.ContentProtectionData InnerXML dans le corps de réponse CPIX, le chiffreur 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 réponse X-Speke-User-Agent HTTP.

  • Un SPEKE-compliant chiffreur agit en tant que client et envoie des opérations POST au point de terminaison du fournisseur de clés.

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

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

  • En cas de réception d'erreurs dans le corps de la réponse, le chiffreur 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 de document CPIX contenant les informations obligatoires, le chiffreur doit s'arrêter et renvoyer 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. En cas d'erreur, le code de réponse HTTP 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 @contentId n'est pas défini

CPIX @contentId manquant

CPIX @version n'est pas défini

CPIX @version manquant

CPIX @version n'est pas pris en charge

CPIX @version non pris en charge

ContentKey@common n'EncryptionScheme est pas défini

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

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

EncryptionScheme Combinaison ContentKey @common non conforme

ContentKey@common n'EncryptionScheme est pas compatible avec la technologie DRM

ContentKey@common EncryptionScheme non compatible avec DRMSystem id (où id est égale à la valeur DRMSystem @systemId)

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

Version SPEKE non prise en charge

Le contrat de cryptage est mal formé

Contrat de cryptage mal formé

Le contrat de cryptage contredit les contraintes des niveaux de sécurité des DRM

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

Le contrat de cryptage ne comprend VideoFilter aucun AudioFilter élément

Contrat de chiffrement CPIX manquant