Secure Packager and Encoder Key Exchange API-Spezifikation - Leitfaden für Partner und Kunden
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Secure Packager and Encoder Key Exchange API-Spezifikation Leitfaden für Partner und Kunden
Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
Secure Packager and Encoder Key Exchange API-Spezifikation: Leitfaden
für Partner und Kunden
Copyright © 2021 Amazon Web Services, Inc. and/or its affiliates. All rights reserved.
Die Marken und Handelsmarken von Amazon dürfen nicht in einer Weise in Verbindung mit nicht von Amazon
stammenden Produkten oder Services verwendet werden, die geeignet ist, Kunden irrezuführen oder Amazon in
irgendeiner Weise herabzusetzen oder zu diskreditieren. Alle anderen Marken, die nicht im Besitz von Amazon sind,
gehören den jeweiligen Besitzern, die möglicherweise mit Amazon verbunden sind oder von Amazon gesponsert
werden.
Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
Table of Contents
Was ist Secure Packager and Encoder Key Exchange? ........................................................................... 1
Allgemeine Architektur ................................................................................................................. 1
Cloud-basierte AWS Architektur .................................................................................................... 2
Erste Schritte ............................................................................................................................. 2
Neu bei SPEKE? ................................................................................................................................ 4
Zugehörige Services und Spezifikationen ....................................................................................... 4
Terminology ............................................................................................................................... 5
Onboarding für Kunden ....................................................................................................................... 6
Holen Sie sich mit einem DRM-Plattformanbieter an Bord ................................................................. 6
SPEKE Support für AWS -Services und -Produkte ........................................................................... 7
SPEKE-API-Spezifikation ..................................................................................................................... 8
Authentication ............................................................................................................................ 8
Authentifizierung für AWS Cloud-Implementierungen ................................................................ 9
Authentifizierung für On-Premise-Produkte .............................................................................. 9
SPEKE-API v1 ......................................................................................................................... 10
SPEKE API v1 - Anpassungen und Einschränkungen bei der DASH-IF-Spezifikation .................... 10
SPEKE API v1 - Standard-Nutzlastkomponenten ................................................................... 11
SPEKE API v1 - Beispiele für den Aufruf von Live-Workflow-Methoden ...................................... 14
SPEKE API v1 - Beispiele für den Aufruf von VOD-Workflow-Methoden ..................................... 17
SPEKE API v1 - Verschlüsselung von Inhaltsschlüsseln .......................................................... 20
SPEKE API v1 - Herzschlag ............................................................................................... 22
SPEKE API v1 - Überschreiben der Schlüsselkennung ........................................................... 23
SPEKE-API v2 ......................................................................................................................... 24
SPEKE API v2 — Anpassungen und Einschränkungen bei der DASH-IF-Spezifikation .................. 25
SPEKE API v2 - Standard-Nutzlastkomponenten ................................................................... 27
SPEKE API v2 - Verschlüsselungsvertrag ............................................................................. 30
SPEKE API v2 - Beispiele für den Aufruf von Live-Workflow-Methoden ...................................... 36
SPEKE API v2 - Beispiele für den Aufruf von VOD-Workflow-Methoden ..................................... 40
SPEKE API v2 - Verschlüsselung von Inhaltsschlüsseln .......................................................... 43
SPEKE API v2 - Überschreiben der Schlüsselkennung ........................................................... 46
License .................................................................................................................................... 47
Creative Commons Namensnennung - Weitergabe unter gleichen Bedingungen 4.0 International
Lizenz ............................................................................................................................. 47
Dokumentverlauf ............................................................................................................................... 53
AWS-Glossar .................................................................................................................................... 55
....................................................................................................................................................... lvi
iii
Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
Allgemeine Architektur
Was ist Secure Packager and
Encoder Key Exchange?
Secure Packager and Encoder Key Exchange (SPEKE) definieren den Standard für die Kommunikation
zwischen Verschlüsselern und Paketen von Medieninhalten und DRM-Schlüsselanbietern (Digital Rights
Management). Die Spezifikation unterstützt Verschlüsseler, die lokal und in der AWS Cloud ausgeführt
werden.
Themen
• Allgemeine Architektur (p. 1)
• Cloud-basierte AWS Architektur (p. 2)
• Erste Schritte (p. 2)
Allgemeine Architektur
Die folgende Abbildung zeigt eine allgemeine Übersicht über die SPEKE-Architektur der
Inhaltsverschlüsselung von für lokale Produkte.
Dies sind die Hauptkomponenten der eben beschriebenen Architektur:
• Verschlüsseler— Stellt die Verschlüsselungstechnologie bereit. Empfängt
Verschlüsselungsanforderungen vom Operator und ruft die benötigten Schlüssel vom DRM-
Schlüsselanbieter ab, um die verschlüsselten Inhalte zu sichern.
• DRM-Plattform-Schlüsselanbieter— Stellt dem Verschlüssler über eine SPEKE-kompatible API
Verschlüsselungsschlüssel bereit. Der Anbieter stellt außerdem Media-Playern Lizenzen für die
Entschlüsselung bereit.
• Player— fordert Schlüssel von demselben DRM-Schlüsselserver an, den der Player und verwendet, um
die Inhalte zu entschlüsseln und den Betrachtern bereitzustellen.
1Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
Cloud-basierte AWS Architektur
Cloud-basierte AWS Architektur
Die folgende Abbildung zeigt die allgemeine Architektur, wenn SPEKE mit Services und Funktionen
verwendet wird, die in der AWS Cloud ausgeführt werden.
Dies sind die Hauptservices und -komponenten:
• Verschlüsseler— Stellt die Verschlüsselungstechnologie in der AWS Cloud bereit. Der Verschlüsseler
erhält Anfragen von seinem Operator und ruft die erforderlichen Verschlüsselungsschlüssel vom DRM-
Schlüsselanbieter über Amazon API Gateway ab, um den verschlüsselten Inhalt zu sichern. Er stellt
die verschlüsselten Inhalte für einen Amazon S3-Bucket oder über eine Amazon CloudFront-Verteilung
bereit.
• AWS IAM und Amazon API Gateway— Verwaltet vertrauenswürdige Kundenrollen und die
Proxykommunikation zwischen dem Verschlüsseler und dem Schlüsselanbieter. API Gateway stellt
Protokollierungsfunktionen bereit und ermöglicht es Kunden, ihre Beziehungen mit dem Verschlüsseler
und dem DRM-System zu steuern. Kunden ermöglichen den Zugriff auf den Schlüsselanbieter über
die Konfiguration der IAM-Rolle. Die API Gateway-API muss sich in der gleichen AWS-Region wie der
Verschlüsseler befinden.
• AWS Certificate Manager(Optional) Stellt der Inhaltsschlüssel-Verschlüsselung eine Zertifikatverwaltung
bereit. Die Verschlüsselung von Inhaltsschlüsseln ist das empfohlene Verfahren, um die Kommunikation
zu sichern. Der Zertifikat-Manager muss sich in der gleichen AWS-Region wie der Verschlüsseler
befinden.
• DRM-Plattform-Schlüsselanbieter— Stellt dem Verschlüssler über eine SPEKE-kompatible API
Verschlüsselungsschlüssel bereit. Der Anbieter stellt außerdem Media-Playern Lizenzen für die
Entschlüsselung bereit.
• Player— fordert Schlüssel von demselben DRM-Schlüsselserver an, den der Player und verwendet, um
die Inhalte zu entschlüsseln und den Betrachtern bereitzustellen.
Erste Schritte
Weitere Einführungsmaterialien zu SPEKE finden Sie unterSie sind noch neu bei SPEKE? (p. 4)aus.
Sind Sie Kunde?
2Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
Erste Schritte
Nehmen Sie Kontakt mit einem AWS Elemental-DRM-Plattformanbieter auf, damit die Verwendung
der Verschlüsselung eingerichtet werden kann. Details dazu finden Sie unter .Onboarding für
Kunden (p. 6)aus.
Sind Sie ein DRM-Plattformanbieter oder ein Kunde mit Ihrem eigenen Schlüsselanbieter?
Stellen Sie Ihrem Schlüsselanbieter eine REST API bereit, die der SPEKE-Spezifikation entspricht. Details
dazu finden Sie unter .SPEKE-API-Spezifikation (p. 8)aus.
3Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
Zugehörige Services und Spezifikationen
Neu bei SPEKE?
Dieser Abschnitt enthält Einführungsmaterial für Leser, die noch nicht mit Secure Packager und Encoder
Key Exchange (SPEKE) vertraut sind.
Sehen Sie sich für eine Einführung in SPEKE den folgenden Webcast an:
Zugehörige Services und Spezifikationen
• API Gateway-BerechtigungenHier finden Sie Informationen dazu, wie Sie den Zugriff auf eine API mit
AWS Identity and Access Management (AWS IAM) -Berechtigungen steuern.
• AWS AssumeRoleHier finden Sie Informationen dazu, wie Sie AWS Security Token Service (AWS STS)
verwenden, um Rollenfunktionalität zu übernehmen.
• AWS Sigv4Signieren einer HTTP-Anforderung mit Signature Version 4.
• DASH-IF-CPIX-Spezifikation v2.0DASH-IF Content Protection Information Exchange Format (CPIX) -
Spezifikation, auf der diese SPEKE v1.0-Spezifikation basiert.
4Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
Terminology
• DASH-IF-CPIX-Spezifikation v2.3DASH-IF Content Protection Information Exchange Format (CPIX) -
Spezifikation, auf der diese SPEKE v2.0-Spezifikation basiert.
• DASH-IF System-IDsHier finden Sie Informationen zur Liste der registrierten IDs für DRM-Systeme.
• https://github.com/awslabs/speke-reference-serverdies ist ein beispielhafter Referenzschlüsselanbieter
für Ihr AWS Konto, um Ihnen bei den ersten Schritten mit einer SPEKE-Implementierung in AWS zu
helfen.
Terminology
Die folgende Liste definiert die in dieser Spezifikation verwendete Terminologie. Sofern möglich, folgt diese
Spezifikation der in der DASH-IF CPIX-Spezifikationverwendeten Terminologie.
• ARNAmazon-Ressourcenname. Eindeutige Bezeichnung einer AWS-Ressource.
• InhaltsschlüsselEin kryptografischer Schlüssel, der für die Verschlüsselung eines Teils des Inhalts
verwendet wird.
• Content-AnbieterDieser Herausgeber, der die Rechte und Regeln für die Bereitstellung geschützter
Medien bereitstellt. Der Inhaltsanbieter stellt möglicherweise auch Quellmedien (Mezzanine-Format zum
Zweck der Transcodierung), Komponenten-IDs, Schlüssel-IDs (Key Identifiers, KIDs), Schlüsselwerte,
Codierungsanweisungen und Metadaten zur Beschreibung der Inhalte bereit.
• DRMDigital Rights Management Wird verwendet, um urheberrechtlich geschützte digitale Inhalte vor
nicht genehmigtem Zugriff zu schützen.
• DRM-PlattformDRM-Funktionalität und -Unterstützung für Inhaltsverschlüsseler und Betrachter
bereitstellt, einschließlich DRM-Schlüssel und Lizenzierung für die Verschlüsselung und Entschlüsselung
von Inhalten.
• DRM-AnbieterDRM-Plattform.
• DRM-SystemEin Standard für DRM-Implementierungen. Häufige DRM-Systeme sind Apple FairPlay,
Google Widevine und Microsoft PlayReady. DRM-Systeme werden von Inhaltsanbietern verwendet, um
digitale Inhalte für die Bereitstellung an Betrachter und für den Zugriff durch Betrachter zu schützen. Eine
Liste der DRM-Systeme, die bei DASH-IF registriert sind, finden Sie unterDASH-IF System-IDsaus. Die
DASH-IF CPIX-Spezifikation verwendet den hier definierten Begriff „DRM-System“ und an einigen Stellen
„DRM-System“, in derselben Bedeutung wie die in diese Spezifikation verwendete Bezeichnung „DRM-
Plattform“.
• DRM-LösungDRM-Plattform.
• DRM-TechnologieDRM-System siehe.
• VerschlüsselerEine Medienverarbeitungskomponente, die Medieninhalte mit vom Schlüsselanbieter
abgerufenen Schlüsseln verschlüsselt. Verschlüsseler fügen den Medien in der Regel auch DRM-
Verschlüsselungssignale und Metadaten hinzu. Verschlüsseler sind in der Regel Encoder, Packager und
Transcoder.
• SchlüsselanbieterEine Komponente einer DRM-Plattform, die eine SPEKE REST-API zur Verarbeitung
von Schlüsselanforderungen bereitstellt. Der Schlüsselanbieter kann der Schlüsselserver selbst oder
eine andere Komponente der Plattform sein.
• SchlüsselserverInhaltskomponente einer DRM-Plattform, die Schlüssel für die Inhaltsverschlüsselung
und -entschlüsselung verwaltet.
• OperatorEine Person, die für den Betrieb des Systems insgesamt verantwortlich ist, einschließlich
Verschlüsseler und Schlüsselanbieter.
• PlayerPlayer der Media-Player, der für einen Betrachter ausgeführt wird. Dieser ruft Informationen aus
verschiedenen Quellen ab, darunter Medienmanifestdateien, Mediendateien und DRM-Lizenzen. Fordert
für die Betrachter-Lizenzen vom DRM-Server an.
5Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
Holen Sie sich mit einem DRM-Plattformanbieter an Bord
Onboarding für Kunden
Schützen Sie Ihre Inhalte vor unbefugter Verwendung, indem Sie einen Digital Rights Management
(DRM) -Schlüsselanbieter von Secure Packager und Encoder Key Exchange (SPEKE) -Schlüsselanbieter
mit Ihrem Verschlüsseler und Ihren Media-Playern kombinieren. SPEKE definiert den Standard für die
Kommunikation zwischen Verschlüsselern und Paketen von Medieninhalten und DRM-Schlüsselanbietern
(Digital Rights Management). Zum Einrichten wählen Sie einen DRM-Plattformschlüsselanbieter aus und
konfigurieren die Kommunikation zwischen dem Schlüsselanbieter und Ihren Verschlüsselern und Playern.
Themen
• Holen Sie sich mit einem DRM-Plattformanbieter an Bord (p. 6)
• SPEKE Support für AWS -Services und -Produkte (p. 7)
Holen Sie sich mit einem DRM-Plattformanbieter an
Bord
Die folgenden Amazon-Partner bieten DRM-Plattformimplementierungen für SPEKE von Drittanbietern an.
Um Details zu den Angeboten und Informationen über die Kontaktaufnahme zu erhalten, klicken Sie auf die
Links zu ihren Amazon Partner Network-Seiten. Partner, für die es keinen Link gibt, besitzen zurzeit keine
Amazon Partner Network-Seite. Sie können sich jedoch direkt an sie wenden. Die Partner können Ihnen bei
der Einrichtung ihrer Plattformen helfen.
DRM-Plattform-Anbieter Unterstützung von SPEKE v1 Unterstützung von SPEKE v2
(AWS Elemental MediaPackage)
Axinom √ √
BuyDRM √ √
castLabs √ √
Conax AS √
EZDRM √
INKA Entworks √ √
Insys Video Technologies √
Intertrust Technologies √ √
Irdeto √
Kaltura √
NAGRA √
NEXTSCAPE, Inc. √
SeaChange √
Verimatrix √
6Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
SPEKE Support für AWS -Services und -Produkte
DRM-Plattform-Anbieter Unterstützung von SPEKE v1 Unterstützung von SPEKE v2
(AWS Elemental MediaPackage)
Viaccess-Orca √
VUALTO √
WebStream √
SPEKE Support für AWS -Services und -Produkte
In diesem Abschnitt wird die SPEKE-Unterstützung von AWS Media Services aufgeführt, die in der AWS
Cloud und von lokalen AWS-Medienprodukten ausgeführt werden. Diese Services und Produkte sind
die Verschlüsseler in der SPEKE-Inhaltsverschlüsselungsarchitektur. Überprüfen Sie, ob Ihr Streaming-
Protokoll und das gewünschte DRM-System für Ihren Service oder Ihr Produkt verfügbar sind.
AWS -Service oder - Unterstützung von Unterstützung von Unterstützte DRM-
Produkt SPEKE v1 SPEKE v2 Technologien
AWS Elemental √ Dokumentation
MediaConvert —
Service, der in der AWS
Cloud ausgeführt wird
AWS Elemental √ √ Dokumentation
MediaPackage —
Service, der in der AWS
Cloud ausgeführt wird
AWS Elemental Live √ Dokumentation: MPEG-
DASH/HLS
AWS Elementar Server √ Dokumentation
— lokales Produkt
7Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
Authentication
SPEKE-API-Spezifikation
Dies ist die REST API-Spezifikation für Secure Packager und Encoder Key Exchange (SPEKE). Mit dieser
Spezifizierung stellen Sie Kunden, die Verschlüsselung verwenden, DRM-Urheberrechtsschutz bereit.
In einem Videostreaming-Workflow kommuniziert die Verschlüsselungs-Engine mit dem Schlüsselanbieter
der DRM-Plattform, um Inhaltsschlüssel anzufordern. Diese Schlüssel sind hoch vertraulich. Daher ist es
von kritischer Bedeutung, dass Schlüsselanbieter und Verschlüsselungs-Engine einen hochsicheren und
vertrauenswürdigen Kommunikationskanal einrichten. Sie können die Inhaltsschlüssel auch im Dokument
verschlüsseln, um eine sicherere durchgängige Verschlüsselung bereitzustellen.
Diese Spezifikation hat folgende Ziele:
• Definieren Sie eine einfache, vertrauenswürdige und hochsichere Schnittstelle, die DRM-Anbieter und
-Kunden für die Integration mit Verschlüsselern verwenden können, wenn eine Inhaltsverschlüsselung
erforderlich ist.
• Decken Sie VOD- sowie Live-Workflows ab und schließen Sie die Fehlerbedingungen und
Authentifizierungsmechanismen ein, die für eine robuste und hochsichere Kommunikation zwischen
Verschlüsselern und DRM-Schlüsselanbieter-Endpunkten erforderlich sind.
• Einschluss von Unterstützung für HLS, MSS und DASH-Packaging und häufig verwendete DRM-
Systeme: FairPlay, PlayReady und Widevine/CENC.
• Einfachheit und Erweiterbarkeit der Spezifikation, um zukünftige DRM-Systeme unterstützen zu können.
• Verwendung einer einfachen REST API.
Note
Copyright 2021, Amazon Web Services, Inc. oder Tochterfirmen. Alle Rechte vorbehalten.
Die Dokumentation wird unter der Creative Commons Namensnennung - Weitergabe unter
gleichen Bedingungen 4.0 International License zur Verfügung gestellt.
DAS HIERIN ENTHALTENE MATERIAL „WIE BESEHEN“, OHNE AUSDRÜCKLICHE
ODER STILLSCHWEIGENDE GEWÄHRLEISTUNG, EINSCHLIESSLICH, ABER NICHT
BESCHRÄNKT AUF DIE GEWÄHRLEISTUNG DER MARKTGÄNGIGKEIT, EIGNUNG FÜR
EINEN BESTIMMTEN ZWECK UND NICHTVERLETZUNG. IN KEINEM FALL HAFTEN DIE
AUTOREN ODER URHEBERRECHTSINHABER DIESES MATERIALS FÜR ANSPRÜCHE,
SCHÄDEN ODER SONSTIGE HAFTUNG, SEI ES IN EINER HANDLUNG DES VERTRAGES,
EINER UNERLAUBTEN HANDLUNG ODER ANDERWEITIG, DIE SICH AUS, AUS ODER
IN VERBINDUNG MIT DIESEM MATERIAL ODER DER VERWENDUNG ODER ANDEREN
HANDLUNGEN DIESES MATERIALS ERGEBEN.
Themen
• Authentication (p. 8)
• SPEKE-API v1 (p. 10)
• SPEKE-API v2 (p. 24)
• License (p. 47)
Authentication
erfordert eine Authentifizierung für lokale Produkte sowie für Services und Funktionen, die in der AWS
Cloud ausgeführt werden.
Themen
• Authentifizierung für AWS Cloud-Implementierungen (p. 9)
8Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
Authentifizierung für AWS Cloud-Implementierungen
• Authentifizierung für On-Premise-Produkte (p. 9)
Authentifizierung für AWS Cloud-Implementierungen
SPEKE erfordert eine AWS Authentifizierung über IAM-Rollen, um mit einem Verschlüsseler verwendet
werden zu können. IAM-Rollen werden vom DRM-Anbieter oder dem Operator erstellt, der im Besitz
des DRM-Endpunkts in einem AWS-Konto ist. Jeder Rolle ist ein Amazon-Ressourcenname (ARN)
zugewiesen, den der AWS Elemental-Service-Operator in der Service-Konsole angibt, wenn er
Verschlüsselung anfordert. Die Richtlinienberechtigungen der Rolle müssen so konfiguriert werden, dass
sie zum Zugriff auf die Schlüsselanbieter-API berechtigen, nicht jedoch auf andere AWS-Ressourcen.
Wenn der Verschlüsseler Kontakt mit dem DRM-Schlüsselanbieter aufnimmt, verwendet er den Rollen-
ARN, um die Rolle des Kontoinhabers des Schlüsselanbieters anzunehmen. Anschließend werden
temporäre Anmeldeinformationen an den Verschlüsseler zurückgegeben, mit denen dieser auf den
Schlüsselanbieter zugreifen kann.
Häufig wird dies so implementiert, dass der Operator oder der DRM-Plattformanbieter dem
Schlüsselanbieter voranstellen und anschließend die AWS Identity and Access Management (AWS IAM)
-Autorisierung auf der API Gateway-Ressource aktivieren. Sie können das folgende Beispiel für eine
Richtliniendefinition einer neuen Rolle anfügen, um der entsprechenden Ressource Berechtigungen zu
erteilen. In diesem Fall gelten die Berechtigungen für alle API Gateway Ressourcen:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"execute-api:Invoke"
],
"Resource": [
"arn:aws:execute-api:us-west-2:*:*/*/GET/*"
]
}
]
}
Schließlich erfordert die Rolle das Hinzufügen einer Vertrauensstellung und der Operator muss den Service
auswählen können.
Das folgende Beispiel zeigt einen Rollen-ARN, der für den Zugriff auf den DRM-Schlüsselanbieter erstellt
wurde:
arn:aws:iam::2949266363526:role/DRMKeyServer
Weitere Informationen zum Erstellen einer Rolle finden Sie unter AWS AssumeRole. Weitere Informationen
zum Signieren einer Anforderung finden Sie unter AWS Sigv4.
Authentifizierung für On-Premise-Produkte
Für lokale Produkte empfehlen wir die Verwendung von SSL/TLS und Digest-Authentifizierung, um die
beste Sicherheit zu erzielen. Sie sollten jedoch mindestens die grundlegende Authentifizierung über HTTPS
verwenden.
Beide Arten der Authentifizierung verwenden den Header Authorization in der HTTP-Anforderung:
• Digst-Authentifizierung— Der Autorisierungs-Header besteht aus dem BezeichnerDigestgefolgt von
einer Reihe von Werten, die die Anforderung authentifizieren. Insbesondere wird ein Antwortwert über
9Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
SPEKE-API v1
eine Reihe von MD5-Hash-Funktionen generiert, die einen eindeutigen, vom Server bereitgestellten
Einmal-Schlüssel einschließen, um sicherzustellen, dass das Passwort sicher übertragen wird.
• Basisauthentifizierung— Der Autorisierungs-Header besteht aus dem BezeichnerBasicgefolgt von einer
Base-64-codierten Zeichenfolge, die den Benutzernamen und das Kennwort darstellt, getrennt durch
einen Doppelpunkt.
Informationen zur Basis- und Digest-Authentifizierung einschließlich detailliertet Informationen zum Header
finden Sie in der Internet Engineering Task Force (IETF) -SpezifikationRFC 2617 - HTTP-Authentifizierung:
Standard- und Digest-Zugriffsauthentifizierungaus.
SPEKE-API v1
Um SPEKE-konform zu sein, muss Ihr DRM-Schlüsselanbieter die in dieser Spezifikation beschriebene
REST-API bereitstellen. Der Verschlüsseler führt API-Aufrufe Ihres Schlüsselanbieters durch.
Note
Die Codebeispiele in dieser Spezifikation dienen lediglich der Illustration. Sie können die Beispiele
nicht ausführen, da sie nicht Teil einer vollständigen SPEKE-Implementierung sind.
Secure Packager und Encoder Key Exchange verwendet die DASH Industry Forum Content Protection
Information Exchange Format (DASH-IF-CPIX) -Datenstrukturdefinition für den Schlüsselaustausch,
wobei einige Einschränkungen gelten. DASH-IF-CPIX definiert ein Schema, um einen erweiterbaren,
Multi-DRM-Austausch zwischen DRM-Plattform und Verschlüsseler zu ermöglichen. So wird für alle
Verpackungsformate mit adaptiven Bitraten zum Zeitpunkt der Inhaltkompression und -verpackung
Inhaltsverschlüsselung bereitgestellt. Zu den Verpackungsformaten mit adaptiven Bitraten gehören HLS,
DASH und MSS.
Detaillierte Informationen zum Austauschformat finden Sie in der DASH Industry Forum CPIX-Spezifikation
unter.https://dashif.org/docs/DASH-IF-CPIX-v2-0.pdfaus.
Themen
• SPEKE API v1 - Anpassungen und Einschränkungen bei der DASH-IF-Spezifikation (p. 10)
• SPEKE API v1 - Standard-Nutzlastkomponenten (p. 11)
• SPEKE API v1 - Beispiele für den Aufruf von Live-Workflow-Methoden (p. 14)
• SPEKE API v1 - Beispiele für den Aufruf von VOD-Workflow-Methoden (p. 17)
• SPEKE API v1 - Verschlüsselung von Inhaltsschlüsseln (p. 20)
• SPEKE API v1 - Herzschlag (p. 22)
• SPEKE API v1 - Überschreiben der Schlüsselkennung (p. 23)
SPEKE API v1 - Anpassungen und Einschränkungen
bei der DASH-IF-Spezifikation
Die DASH-IF CPIX-Spezifikationhttps://dashif.org/docs/DASH-IF-CPIX-v2-0.pdfunterstützt eine Reihe von
Anwendungsfällen und Topologien. Die SPEKE-API-Spezifikation entspricht der CPIX-Spezifikationen,
abgesehen von den folgenden Anpassungen und Einschränkungen:
• SPEKE folgt dem Verschlüsseler-Consumer-Workflow.
• SPEKE wendet die folgenden Einschränkungen auf verschlüsselte Inhaltsschlüssel an:
• SPEKE unterstützt keine digitale Signaturüberprüfung (XMLDSIG) für Anforderungs- oder
Antwortnutzlasten.
• SPEKE erfordert 2048 RSA-basierte Zertifikate.
10Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
SPEKE API v1 - Standard-Nutzlastkomponenten
• Für rotierende Schlüssel-Workflows benötigt SPEKE
dieContentKeyUsageRulefilter,KeyPeriodFilter. SPEKE ignores all other
`ContentKeyUsageRule-Einstellungen.
• SPEKE-verwendet dieUpdateHistoryItemList-Funktionalität nicht. Wenn die Liste in der Antwort
vorhanden ist, wird sie von SPEKE ignoriert.
• SPEKE unterstützt die Schlüsselrotation. SPEKE verwendet für die Nachverfolgung des
Schlüsselzeitraums nur die `ContentKeyPeriod @index.
• SPEKE verwendet zur Unterstützung von MSS PlayReady einen benutzerdefinierten Parameter unter
derDRMSystem-Tag,SPEKE:ProtectionHeaderaus.
• Wenn bei einer HLS-Verpackung URIExtXKey in der Antwort enthalten ist, muss sie die vollständigen
Daten enthalten, die dem URI-Parameter des Tag EXT-X-KEY einer HLS-Wiedergabeliste ohne weitere
Signalisierungsanforderung hinzugefügt werden sollen.
• Für HLS-Wiedergabeliste klicken Sie unter derDRMSystem-Tag, bietet SPEKE die optionalen
benutzerdefinierten Parameterspeke:KeyFormatundspeke:KeyFormatVersions, für die Werte
derKEYFORMATundKEYFORMATVERSIONS-Parameter desEXT-X-KEY-Tag.
Der HLS-Initialisierungsvektor (IV) folgt stets der Segmentnummer, es sei denn, dies wird vom Operator
ausdrücklich anders festgelegt.
• Beim Anfordern von Schlüsseln verwendet der Verschlüsseler möglicherweise das optionale Attribut
@explicitIV des Elements ContentKey. Der Schlüsselanbieter kann mit einem IV unter Verwendung
von @explicitIV antworten, auch wenn das Attribut nicht in der Anforderung enthalten ist.
• Die Verschlüsseler erstellt die Schlüssel-ID (KID), die für alle Inhalts-IDs und Schlüsselzeiträume gleich
bleibt. Der Schlüsselanbieter schließt KID in seiner Antwort auf das Anforderungsdokument ein.
• Der Schlüsselanbieter enthält möglicherweise einen Wert für den Speke-User-Agent-Antwort-Header,
um sich zu Debugging-Zwecken zu identifizieren.
• SPEKE unterstützt zurzeit nicht mehrere Tracks oder Schlüssel pro Inhalt.
Der SPEKE-kompatible Verschlüssler fungiert als Client und sendetPOST-Vorgänge an den Endpunkt
des Schlüsselanbieters. Der Verschlüsseler sendet möglicherweise eine regelmäßige heartbeat-
Anforderung, um sicherzustellen, dass die Verbindung zwischen dem Verschlüsseler und dem
Schlüsselanbieter-Endpunkt stabil ist.
SPEKE API v1 - Standard-Nutzlastkomponenten
Der Verschlüsseler kann in allen SPEKE-Anforderungen Antworten für mindestens ein DRM-
System anfordern. Der Verschlüsseler gibt die DRM-Systeme in der
Anforderungsnutzlast an. Jede Systemspezifikation enthält den Schlüssel und gibt den Typ der
zurückzugebenden Antwort an.
Das folgende Beispiel zeigt eine DRM-Systemliste mit einer einzigen DRM-Systemspezifikation:
In der folgenden Tabelle werden die Hauptkomponenten für jedes aufgelistet.
11Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
SPEKE API v1 - Standard-Nutzlastkomponenten
ID Beschreibung
systemId oder schemeId Eindeutige ID für den Typ des DRM-Systems wie
bei der DASH-IF-Organisation registriert. Unter
DASH-IF-System-IDs finden Sie eine Liste.
kid Die -Schlüssel-ID. Dies ist nicht der eigentliche
Schlüssel, sondern eine ID, die in einer Hash-
Tabelle auf den Schlüssel verweist.
Fordert einen unverschlüsselten Standardschlüssel
an. Der Schlüsselantworttyp muss entweder diese
oder die PSSH-Antwort sein.
Fordert einen Protection System Specific Header
(PSSH) an. Diese Art von Header enthält
einen Verweis auf die kid, die systemID und
benutzerdefinierte Daten für den DRM-Anbieter
als Teil von Common Encryption (CENC). Der
Schlüsselantworttyp muss entweder diese oder die
UriExtXKey-Antwort sein.
_Beispielanforderungen für Standardschlüssel und PSSH _
Das folgende Beispiel zeigt einen Teil einer Beispielanforderung des Verschlüsselers an den DRM-
Schlüsselanbieter. Die Hauptkomponenten sind hervorgehoben. Die erste Anforderung bezieht sich auf
einen Standardschlüssel. Die zweite Anforderung bezieht sich auf eine PSSH-Antwort:
12Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
SPEKE API v1 - Standard-Nutzlastkomponenten
_Beispielantworten für Standardschlüssel und PSSH _
Das folgende Beispiel zeigt die entsprechende Antwort des DRM-Schlüsselanbieters für den
Verschlüsseler:
13Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
SPEKE API v1 - Beispiele für den
Aufruf von Live-Workflow-Methoden
SPEKE API v1 - Beispiele für den Aufruf von Live-
Workflow-Methoden
Beispiel für eine Anforderungssyntax
Die folgende URL ist lediglich ein Beispiel und gibt kein bestimmtes Format vor:
POST https://speke-compatible-server/speke/v1.0/copyProtection
Anforderungstext
Ein CPIX-Element.
14Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
SPEKE API v1 - Beispiele für den
Aufruf von Live-Workflow-Methoden
Anforderungsheader
Name Typ Auftreten Beschreibung
AWS Authorization Zeichenfolge 1..1 Weitere Informationen
finden Sie unter AWS
Sigv4.
X-Amz-Security- Zeichenfolge 1..1 Weitere Informationen
Token finden Sie unter AWS
Sigv4.
X-Amz-Date Zeichenfolge 1..1 Weitere Informationen
finden Sie unter AWS
Sigv4.
Content-Type Zeichenfolge 1..1 application/xml
Antwort-Header
Name Typ Auftreten Beschreibung
Speke-User-Agent Zeichenfolge 1..1 Zeichenfolge, die den
Schlüsselanbieter
identifiziert.
Content-Type Zeichenfolge 1..1 application/xml
Request Response (Antwort anfordern)
HTTP-CODE Name der Nutzlast Auftreten Beschreibung
200 (Success) CPIX 1..1 DASH-CPIX-
Nutzlastantwort
4XX (Client error) Client-Fehlermeldung 1..1 Beschreibung des
Client-Fehlers.
5XX (Server error) Server-Fehlermeldung 1..1 Beschreibung des
Server-Fehlers.
Note
Die Beispiele in diesem Abschnitt zeigen keine Inhaltsschlüssel-Verschlüsselung. Informationen
zum Hinzufügen von Inhaltsschlüssel-Verschlüsselung finden Sie unterVerschlüsselung von
Inhalten (p. 20)aus.
Beispiel für eine Live-Anforderungsnutzlast mit entschlüsselten Schlüsseln
Das folgende Beispiel zeigt eine typische Live-Anforderungsnutzlast vom Verschlüsseler an den DRM-
Schlüsselanbieter:
15Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
SPEKE API v1 - Beispiele für den
Aufruf von Live-Workflow-Methoden
Beispiel für eine Live-Antwortnutzlast mit entschlüsselten Schlüsseln
Das folgende Beispiel zeigt eine typische Antwortnutzlast des DRM-Schlüsselanbieters:
5dGAgwGuUYu4dHeHtNlxJw==
16Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
SPEKE API v1 - Beispiele für den
Aufruf von VOD-Workflow-Methoden
aHR0cHM6Ly83azR5dHV4cTVkLmV4ZWN1dGUtYXBpLnVzLXdlc3QtMi5hbWF6b25hd3MuY29tL0VrZVN0YWdlL
cpix:URIExtXKey>
aWRlbnRpdHk=
MQ==
aHR0cHM6Ly83azR5dHV4cTVkLmV4ZWN1dGUtYXBpLnVzLXdlc3QtMi5hbWF6b25hd3MuY29tL0VrZVN0YWdlL
cpix:URIExtXKey>
Y29tLmFwcGxlLnN0cmVhbWluZ2tleWRlbGl2ZXJ5
MQ==
AAAAanBzc2gAAAAA7e
+LqXnWSs6jyCfc1R0h7QAAAEoIARIQeSIcblaNbb7Dji6sAtKZzRoNd2lkZXZpbmVfdGVzdCIfa2V5LWlkOmVTSWNibGFOYmI3RGppN
cpix:PSSH>
CgMAAAEAAQAAAzwAVwBSAE0ASABFAEEARABFAFIAIAB4AG0AbABuAHMAPQAiAGgAdAB0AHAAOgAvAC
+ADwAQQBMAEcASQBEAD4AQQBFAFMAQwBUAFIAPAAvAEEATABHAEkARAA
+ADwALwBQAFIATwBUAEUAQwBUAEkATgBGAE8APgA8AEsASQBEAD4ATwBXAGoAaAB0AHIAMwB1ADkAawArAHIAZABvADEASQBMAFkAMA
+AGgAdAB0AHAAOgAvAC8AcABsAGEAeQByAGUAYQBkAHkALgBkAGkAcgBlAGMAdAB0AGEAcABzAC4AbgBlAHQALwBwAHIALwBzAHYAYw
+ADwALwBXAFIATQBIAEUAQQBEAEUAUgA+AA==
AAADMHBzc2gAAAAAmgTweZhAQoarkuZb4IhflQAAAxAQAwAAAQABAAYDPABXAFIATQBIAEUAQQBEAEUAUgAgAHgAbQB
+ADwASwBFAFkATABFAE4APgAxADYAPAAvAEsARQBZAEwARQBOAD4APABBAEwARwBJAEQAPgBBAEUAUwBDAFQAUgA8AC8AQQBMAEcASQ
+ADwASwBJAEQAPgBiAGgAdwBpAGUAWQAxAFcAdgBtADMARABqAGkANgBzAEEAdABLAFoAegBRAD0APQA8AC8ASwBJAEQAPgA8AEMASA
+AGEAVABtAFAASgBWAEMAVgBaADYAcwA9ADwALwBDAEgARQBDAEsAUwBVAE0APgA8AEwAQQBfAFUAUgBMAD4AaAB0AHQAcABzADoALw
+ADwALwBEAEEAVABBAD4APAAvAFcAUgBNAEgARQBBAEQARQBSAD4A
SPEKE API v1 - Beispiele für den Aufruf von VOD-
Workflow-Methoden
Beispiel für eine Anforderungssyntax
Die folgende URL ist lediglich ein Beispiel und gibt kein bestimmtes Format vor.
POST https://speke-compatible-server/speke/v1.0/copyProtection
Anforderungstext
17Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
SPEKE API v1 - Beispiele für den
Aufruf von VOD-Workflow-Methoden
Ein CPIX-Element.
Antwort-Header
Name Typ Auftreten Beschreibung
Speke-User-Agent Zeichenfolge 1..1 Zeichenfolge, die den
Schlüsselanbieter
identifiziert.
Content-Type Zeichenfolge 1..1 application/xml
Request Response (Antwort anfordern)
HTTP-CODE Name der Nutzlast Auftreten Beschreibung
200 (Success) CPIX 1..1 DASH-CPIX-
Nutzlastantwort
4XX (Client error) Client-Fehlermeldung 1..1 Beschreibung des
Client-Fehlers.
5XX (Server error) Server-Fehlermeldung 1..1 Beschreibung des
Server-Fehlers.
Note
Die Beispiele in diesem Abschnitt zeigen keine Inhaltsschlüssel-Verschlüsselung. Informationen
zum Hinzufügen von Inhaltsschlüssel-Verschlüsselung finden Sie unterVerschlüsselung von
Inhalten (p. 20)aus.
Beispiel für eine VOD-Anforderungsnutzlast mit entschlüsselten Schlüsseln
Das folgende Beispiel zeigt eine grundlegende VOD-Anforderungsnutzlast vom Verschlüsseler an den
DRM-Schlüsselanbieter:
18Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
SPEKE API v1 - Beispiele für den
Aufruf von VOD-Workflow-Methoden
Beispiel für eine VOD-Antwortnutzlast mit entschlüsselten Schlüsseln
Das folgende Beispiel zeigt eine grundlegende VOD-Antwortnutzlast des DRM-Schlüsselanbieters:
5dGAgwGuUYu4dHeHtNlxJw==
aHR0cHM6Ly83azR5dHV4cTVkLmV4ZWN1dGUtYXBpLnVzLXdlc3QtMi5hbWF6b25hd3MuY29tL0VrZVN0YWdlL
cpix:URIExtXKey>
aWRlbnRpdHk=
MQ==
aHR0cHM6Ly83azR5dHV4cTVkLmV4ZWN1dGUtYXBpLnVzLXdlc3QtMi5hbWF6b25hd3MuY29tL0VrZVN0YWdlL
cpix:URIExtXKey>
Y29tLmFwcGxlLnN0cmVhbWluZ2tleWRlbGl2ZXJ5
MQ==
AAAAanBzc2gAAAAA7e
+LqXnWSs6jyCfc1R0h7QAAAEoIARIQeSIcblaNbb7Dji6sAtKZzRoNd2lkZXZpbmVfdGVzdCIfa2V5LWlkOmVTSWNibGFOYmI3RGppN
cpix:PSSH>
19Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
SPEKE API v1 - Verschlüsselung von Inhaltsschlüsseln
CgMAAAEAAQAAAzwAVwBSAE0ASABFAEEARABFAFIAIAB4AG0AbABuAHMAPQAiAGgAdAB0AHAAOgAvAC
+ADwAQQBMAEcASQBEAD4AQQBFAFMAQwBUAFIAPAAvAEEATABHAEkARAA
+ADwALwBQAFIATwBUAEUAQwBUAEkATgBGAE8APgA8AEsASQBEAD4ATwBXAGoAaAB0AHIAMwB1ADkAawArAHIAZABvADEASQBMAFkAMA
+AGgAdAB0AHAAOgAvAC8AcABsAGEAeQByAGUAYQBkAHkALgBkAGkAcgBlAGMAdAB0AGEAcABzAC4AbgBlAHQALwBwAHIALwBzAHYAYw
+ADwALwBXAFIATQBIAEUAQQBEAEUAUgA+AA==
AAADMHBzc2gAAAAAmgTweZhAQoarkuZb4IhflQAAAxAQAwAAAQABAAYDPABXAFIATQBIAEUAQQBEAEUAUgAgAHgAbQB
+ADwASwBFAFkATABFAE4APgAxADYAPAAvAEsARQBZAEwARQBOAD4APABBAEwARwBJAEQAPgBBAEUAUwBDAFQAUgA8AC8AQQBMAEcASQ
+ADwASwBJAEQAPgBiAGgAdwBpAGUAWQAxAFcAdgBtADMARABqAGkANgBzAEEAdABLAFoAegBRAD0APQA8AC8ASwBJAEQAPgA8AEMASA
+AGEAVABtAFAASgBWAEMAVgBaADYAcwA9ADwALwBDAEgARQBDAEsAUwBVAE0APgA8AEwAQQBfAFUAUgBMAD4AaAB0AHQAcABzADoALw
+ADwALwBEAEEAVABBAD4APAAvAFcAUgBNAEgARQBBAEQARQBSAD4A
SPEKE API v1 - Verschlüsselung von
Inhaltsschlüsseln
Sie können optional Ihrer SPEKE-Implementierung optional eine Inhaltsschlüssel-Verschlüsselung
hinzufügen. Die Inhaltsschlüssel-Verschlüsselung garantiert einen vollständigen und durchgängigen
Schutz, indem nicht nur die Inhalte für die Übertragung verschlüsselt werden, sondern auch die
Inhaltsschlüssel. Wenn Sie dies für Ihren Schlüsselanbieter nicht implementieren, sind Sie hinsichtlich der
Sicherheit von der Transportebenen-Verschlüsselung und einer robusten Authentifizierung abhängig.
Um die Inhaltsschlüssel-Verschlüsselung für Verschlüsseler zu verwenden, die in der AWS Cloud
verwendet wird, importieren Kunden Zertifikate in den AWS Certificate Manager und verwenden
anschließend die resultierenden Zertifikat-ARNs für ihre Verschlüsselungsaktionen. Der Verschlüsseler
verwendet die Zertifikat-ARNs und den ACM--Service, um dem DRM-Schlüsselanbieter verschlüsselte
Inhaltsschlüssel bereitzustellen.
Restrictions
SPEKE unterstützt die Inhaltsschlüssel-Verschlüsselung wie in der DASH-IF-CPIX-Spezifizierung
spezifiziert, abgesehen von den folgenden Einschränkungen:
• SPEKE unterstützt keine digitale Signaturüberprüfung (XMLDSIG) für Anforderungs- oder
Antwortnutzlasten.
• SPEKE erfordert 2048 RSA-basierte Zertifikate.
Diese Einschränkungen werden auch inAnpassungen und Einschränkungen bei der DASH-IF-
Spezifikation (p. 10)aus.
Implementieren der Inhaltsschlüssel-Verschlüsselung
Um Inhaltsschlüssel-Verschlüsselung bereitzustellen, führen Sie in den Implementierungen Ihres DRM-
Schlüsselanbieters Folgendes aus:
• Verarbeiten Sie das Element in den Anforderungs- und
Antwortnutzlasten.
• Stellen Sie in der der Antwortnutzlasten verschlüsselte Werte bereit.
Weitere Informationen zu diesen Elementen finden Sie in der DASH-IF CPIX 2.0-Spezifikation.
Beispiel für das Inhaltsschlüssel-Verschlüsselungselement in der
Anforderungsnutzlast
20Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
SPEKE API v1 - Verschlüsselung von Inhaltsschlüsseln
Im folgenden Beispiel wird das hinzugefügte -Element in Fettschrift
hervorgehoben:
...
Beispiel für das Inhaltsschlüssel-Verschlüsselungselement in der
Antwortnutzlast
Im folgenden Beispiel wird das hinzugefügte -Element in Fettschrift
hervorgehoben:
qnei/5TsfUwDu+8bhsZrLjDRDngvmnUZD2eva7SfXWw=
21Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
SPEKE API v1 - Herzschlag
DGqdpHUfFKxdsO9+EWrPjtdTCVfjPLwwtzEcFC/j0xY=
...
Beispiel für das Inhaltsschlüssel-Verschlüsselungselement in der
Antwortnutzlast
Das folgende Beispiel zeigt die Behandlung des verschlüsselten Inhaltsschlüssels
im -Element der Antwortnutzlast. Hier wird das Element
verwendet:
NJYebfvJ2TdMm3k6v
+rLNVYb0NoTJoTLBBdbpe8nmilEfp82SKa7MkqTn2lmQBPB
t9lW4WCebfS1GP+dh0IicMs+2+jnrAmfDa4WU6VGHc4=
Im Vergleich dazu zeigt das folgende Beispiel eine ähnliche Antwortnutzlast mit dem unverschlüsselten
Inhaltsschlüssel als entschlüsselter Schlüssel. Hier wird das Element verwendet:
5dGAgwGuUYu4dHeHtNlxJw==
SPEKE API v1 - Herzschlag
Beispiel für eine Anforderungssyntax
Die folgende URL ist lediglich ein Beispiel und gibt kein bestimmtes Format vor:
GET https://speke-compatible-server/speke/v1.0/heartbeat
Request Response (Antwort anfordern)
22Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
SPEKE API v1 - Überschreiben der Schlüsselkennung
HTTP-CODE Name der Nutzlast Auftreten Beschreibung
200 (Success) Statusmeldung 1..1 Eine Nachricht, die den
Status beschreibt.
SPEKE API v1 - Überschreiben der Schlüsselkennung
Der Verschlüsseler erstellt bei jeder Rotation der Schlüssel eine neue Schlüssel-ID (Key Identifier, KID). Er
übergibt die KID an den DRM-Schlüsselanbieter bei dessen Anforderungen. Beinahe immer antwortet der
Schlüsselanbieter mit derselben KID. Er kann jedoch in der Antwort auch einen anderen Wert für die KID
bereitstellen.
Im Folgenden finden Sie eine Beispielanforderung mit der KID
11111111-1111-1111-1111-111111111111:
Die folgende Antwort überschreibt die KID zu 22222222-2222-2222-2222-222222222222:
p3dWaHARtL97MpT7TE916w==
AAAAanBzc2gAAAAA7e
+LqXnWSs6jyCfc1R0h7QAAAEoIARIQeSIcblaNbb7Dji6sAtKZzRoNd2lkZXZpbmVfdGVzdCIfa2V5LWlkOmVTSWNibGFOYmI3RGppN
cpix:PSSH>
23Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
SPEKE-API v2
SPEKE-API v2
Um SPEKE-konform zu sein, muss Ihr DRM-Schlüsselanbieter die in dieser Spezifikation beschriebene
REST-API bereitstellen. Der Verschlüsseler führt API-Aufrufe Ihres Schlüsselanbieters durch.
Note
Die Codebeispiele in dieser Spezifikation dienen lediglich der Illustration. Sie können die Beispiele
nicht ausführen, da sie nicht Teil einer vollständigen SPEKE-Implementierung sind.
Secure Packager und Encoder Key Exchange verwendet die DASH Industry Forum Content Protection
Information Exchange Format (DASH-IF-CPIX) -Datenstrukturdefinition für den Schlüsselaustausch,
wobei einige Einschränkungen gelten. DASH-IF-CPIX definiert ein Schema, um einen erweiterbaren,
Multi-DRM-Austausch zwischen DRM-Plattform und Verschlüsseler zu ermöglichen. So wird für alle
Verpackungsformate mit adaptiven Bitraten zum Zeitpunkt der Inhaltkompression und -verpackung
Inhaltsverschlüsselung bereitgestellt. Zu den Verpackungsformaten mit adaptiven Bitraten gehören HLS,
DASH und MSS.
Beginnend mit der Version 2.0 ist SPEKE auf eine bestimmte CPIX-Version ausgerichtet:
Auf der SPEKE Seite wird dies durch die Verwendung derX-Speke-VersionHTTP-Header und auf
der CPIX-Seite durch die Verwendung desCPIX@versionAttribut. Ein Fehlen dieser Elemente in den
Anforderungen ist typisch für SPEKE v1-Legacy-Workflows. In SPEKE v2-Workflows wird erwartet, dass
der Schlüsselanbieter CPIX-Dokumente nur verarbeiten, wenn er beide Versionsparameter unterstützt.
Detaillierte Informationen zum Austauschformat finden Sie im DASH Industry ForumCPIX 2.3aus.
Insgesamt bringt SPEKE v2.0 die folgenden Entwicklungen im Vergleich zu SPEKE v1.0:
• Alle Tags aus dem SPEKE-XML-Namespace sind zugunsten äquivalenter Tags im CPIX-XML-
Namespace veraltet
• SPEKE:ProtectionHeaderist veraltet und ersetzt
durchCPIX:DRMSystem.SmoothStreamingProtectionHeaderData
• CPIX:URIExtXKey,SPEKE:KeyFormatundSPEKE:KeyFormatVersionssind veraltet und
durchCPIX:DRMSystem.HLSSignalingData
• CPIX@idwird ersetzt durchCPIX@contentId
• Neue obligatorische CPIX-Attribute:CPIX@version,ContentKey@commonEncryptionScheme
• Neues optionales CPIX-Element:DRMSystem.ContentProtectionData
• Support für mehrere Inhaltsschlüssel
• Versionsübergreifender Mechanismus zwischen SPEKE und CPIX
• Entwicklung von HTTP-Headern: neuX-Speke-VersionHeader,Speke-User-Agent-Header wurde
umbenanntX-Speke-User-Agent
• Deprecation der Heartbeat-API
24Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
SPEKE API v2 — Anpassungen und
Einschränkungen bei der DASH-IF-Spezifikation
Da die Spezifikation SPEKE v1.0 unverändert bleibt, müssen vorhandene Implementierungen nicht
geändert werden, um SPEKE v1.0 Workflows weiterhin zu unterstützen.
Themen
• SPEKE API v2 — Anpassungen und Einschränkungen bei der DASH-IF-Spezifikation (p. 25)
• SPEKE API v2 - Standard-Nutzlastkomponenten (p. 27)
• SPEKE API v2 - Verschlüsselungsvertrag (p. 30)
• SPEKE API v2 - Beispiele für den Aufruf von Live-Workflow-Methoden (p. 36)
• SPEKE API v2 - Beispiele für den Aufruf von VOD-Workflow-Methoden (p. 40)
• SPEKE API v2 - Verschlüsselung von Inhaltsschlüsseln (p. 43)
• SPEKE API v2 - Überschreiben der Schlüsselkennung (p. 46)
SPEKE API v2 — Anpassungen und Einschränkungen
bei der DASH-IF-Spezifikation
Das DASH Industry ForumCPIX 2.3unterstützt eine Reihe von Anwendungsfällen und Topologien. Die
Spezifikation SPEKE API v2.0 definiert sowohl ein CPIX-Profil als auch eine API für CPIX. Um diese beiden
Ziele zu erreichen, entspricht es der CPIX-Spezifikationen, abgesehen von den folgenden Anpassungen
und Einschränkungen:
CPIX-Profil
• SPEKE folgt dem Verschlüsseler-Consumer-Workflow.
• SPEKE wendet die folgenden Einschränkungen auf verschlüsselte Inhaltsschlüssel an:
• SPEKE unterstützt keine digitale Signaturüberprüfung (XMLDSIG) für Anforderungs- oder
Antwortnutzlasten.
• SPEKE erfordert 2048 RSA-basierte Zertifikate.
• SPEKE nutzt nur eine Teilmenge von CPIX-Funktionalitäten:
• SPEKE-verwendet dieUpdateHistoryItemList-Funktionalität nicht. Wenn die Liste in der Antwort
vorhanden ist, wird sie von SPEKE ignoriert.
• SPEKE verzichtet auf die Root-/Leaf Key-Funktionalität. Wenn das
SymbolContentKey@dependsOnKeySPEKE ignoriert es.
• SPEKE-verwendet dieBitrateFilter-Element undVideoFilter@wcgAttribut. Wenn diese
Elemente oder Attribute in der CPIX-Payload vorhanden sind, ignoriert SPEKE sie.
• Nur die Elemente oder Attribute, die auf derSeite „Standardnutzlast-Komponenten“ (p. 27)oder
dieInhaltsschlüssel-Verschlüsselung (p. 30)kann in CPIX-Dokumenten verwendet werden, die mit
SPEKE v2 ausgetauscht werden.
• Wenn der Verschlüsseler in einer CPIX-Anforderung enthalten ist, müssen alle Elemente und Attribute
einen gültigen Wert in der CPIX-Antwort des Schlüsselanbieters enthalten. Wenn nicht, muss der
Verschlüsseler anhalten und einen Fehler auslösen.
• SPEKE unterstützt die Schlüsselrotation mitKeyPeriodFilter-Elemente. SPEKE verwendet nur
dieContentKeyPeriod@indexverwenden, um die Schlüsselperiode zu verfolgen.
• Für HLS-Signalisierung, mehrereDRMSystem.HLSSignalingDataElemente müssen verwendet
werden: eins mit einemDRMSystem.HLSSignalingData@playlistAttributwert von 'media' und ein
anderer mit einemDRMSystem.HLSSignalingData@playlistAttributwert von 'master'.
• Beim Anfordern von Schlüsseln verwendet der Verschlüsseler möglicherweise das optionale Attribut
@explicitIV des Elements ContentKey. Der Schlüsselanbieter kann mit einem IV unter Verwendung
von @explicitIV antworten, auch wenn das Attribut nicht in der Anforderung enthalten ist.
• Die Verschlüsseler erstellt die Schlüssel-ID (KID), die für alle Inhalts-IDs und Schlüsselzeiträume gleich
bleibt. Der Schlüsselanbieter schließt KID in seiner Antwort auf das Anforderungsdokument ein.
25Secure Packager and Encoder Key Exchange API-
Spezifikation Leitfaden für Partner und Kunden
SPEKE API v2 — Anpassungen und
Einschränkungen bei der DASH-IF-Spezifikation
• Der Verschlüsseler muss einen Wert für dieCPIX@contentIdAttribut. Wenn ein leerer Wert für dieses
Attribut erhalten wird, muss der Schlüsselanbieter einen Fehler mit der Beschreibung 'Missing CPIX
@contentId 'zurückgeben.CPIX@contentId-Wert kann vom Schlüsselanbieter nicht überschrieben
werden.
CPIX@id-Wert, wenn nicht null, vom Schlüsselanbieter ignoriert werden.
• Der Verschlüsseler muss einen Wert für dieCPIX@versionAttribut. Wenn ein leerer Wert für dieses
Attribut erhalten wird, muss der Schlüsselanbieter einen Fehler mit der Beschreibung 'Missing CPIX
@version 'zurückgeben. Wenn Sie eine Anfrage mit einer nicht unterstützten Version erhalten, lautet die
vom Schlüsselanbieter zurückgegebene Fehlerbeschreibung „Nicht unterstützte CPIX @version“.
CPIX@version-Wert kann vom Schlüsselanbieter nicht überschrieben werden.
• Der Verschlüsseler muss einen Wert für dieContentKey@commonEncryptionScheme-Attribut
für jeden angeforderten Schlüssel. Wenn Sie einen leeren Wert für dieses Attribut erhalten, gibt der
Schlüsselanbieter einen Fehler mit der Beschreibung 'Missing contentKey @commonEncryptionScheme
for KIDid '.
Ein eindeutiges CPIX-Dokument kann nicht mehrere Werte für
verschiedeneContentKey@commonEncryptionScheme-Attribute. Bei Erhalt einer solchen
Kombination muss der Schlüsselanbieter einen Fehler mit der Beschreibung „Nicht konforme ContentKey
@commonEncryptionScheme -Kombination“ zurückgeben.
Nicht alleContentKey@commonEncryptionScheme-Werte sind mit allen DRM-Technologien
kompatibel. Bei Erhalt einer solchen Kombination muss der Schlüsselanbieter einen Fehler mit der
Beschreibung „ContentKey @commonEncryptionScheme nicht kompatibel mit DRMSystemid '.
ContentKey@commonEncryptionScheme-Wert kann vom Schlüsselanbieter nicht überschrieben
werden.
• Wenn Sie unterschiedliche Werte
fürDRMSystem@PSSHundDRMSystem.ContentProtectionDataInnerXML-Element im CPIX-
Antworttext angeben, muss der Verschlüsseler anhalten und einen Fehler auslösen.
API für CPIX
• Der Schlüsselanbieter muss einen Wert für dieX-Speke-User-AgentHTTP-Antwort-Header.
• Ein SPEKE-kompatibler Verschlüsseler fungiert als Client und sendet POST-Operationen an den
Schlüsselanbieter-Endpunkt.
• Der Verschlüsseler muss einen Wert für dieX-Speke-VersionHTTP-Request-Header mit der SPEKE-
Version, die mit der Anforderung verwendet wird, formuliert als MajorVersion.MinorVersion, wie '2.0'
für SPEKE v2.0. Wenn der Schlüsselanbieter die vom Verschlüsseler für die aktuelle Anforderung
verwendete SPEKE-Version nicht unterstützt, muss der Schlüsselanbieter einen Fehler mit der
Beschreibung „Nicht unterstützte SPEKE-Version“ zurückgeben und nicht versuchen, das CPIX-
Dokument nach bestem Aufwand zu verarbeiten.
DieX-Speke-Version-Headerwert, der vom Verschlüsseler definiert wurde, kann vom
Schlüsselanbieter in der Antwort auf die Anforderung nicht geändert werden.
• Wenn Fehler im Antworttext empfangen werden, muss der Verschlüsseler einen Fehler auslösen und die
Anforderung nicht mit einer SPEKE v1.0 Versionierung wiederholen.
Wenn der Schlüsselanbieter keinen Fehler zurückgibt, aber kein CPIX-Dokument zurückgibt, das die
obligatorischen Informationen enthält, sollte der Verschlüsseler anhalten und einen Fehler auslösen.
In der folgenden Tabelle werden die Standardnachrichten zusammengefasst, die vom Schlüsselanbieter im
Nachrichtentext zurückgegeben werden müssen. Der HTTP-Antwortcode in Fehlerfällen muss ein 4XX oder
26Sie können auch lesen
