Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # SPEKE API-Spezifikation Dies ist die REST-API-Spezifikation für Secure Packager and 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 auch die Inhaltsschlüssel im Dokument verschlüsseln, um eine sicherere Verschlüsselung zu gewährleisten. end-to-end 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. + Beinhaltet Unterstützung für HLS-, MSS- und DASH-Pakete und ihre gängigen 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. **Anmerkung** Copyright 2021, Amazon Web Services, Inc. oder seine verbundenen Unternehmen. Alle Rechte vorbehalten. Die Dokumentation wird unter der Creative Commons ShareAlike Attribution-4.0 International License zur Verfügung gestellt. DAS HIERIN ENTHALTENE MATERIAL WIRD „WIE ES IST“ ZUR VERFÜGUNG GESTELLT, OHNE JEGLICHE AUSDRÜCKLICHE ODER STILLSCHWEIGENDE GARANTIE, EINSCHLIESSLICH, ABER NICHT BESCHRÄNKT AUF GARANTIEN DER MARKTGÄNGIGKEIT, EIGNUNG FÜR EINEN BESTIMMTEN ZWECK UND NICHTVERLETZUNG VON RECHTEN DRITTER. IN KEINEM FALL HAFTEN DIE AUTOREN ODER URHEBERRECHTSINHABER DIESES MATERIALS FÜR ANSPRÜCHE, SCHÄDEN ODER ANDERE VERBINDLICHKEITEN, SEI ES AUS VERTRAG, UNERLAUBTER HANDLUNG ODER AUF ANDERE WEISE, DIE SICH AUS, AUS ODER IN VERBINDUNG MIT DIESEM MATERIAL ODER DER VERWENDUNG ODER ANDEREN GESCHÄFTEN MIT DIESEM MATERIAL ERGEBEN. **Topics** + [Für SPEKE ist eine Authentifizierung erforderlich](authentication.md) + [SPEKE API v1](the-speke-api.md) + [SPEKE API v2](the-speke-api-v2.md) + [Lizenz für die SPEKE API-Spezifikation](license.md) # Für SPEKE ist eine Authentifizierung erforderlich SPEKE erfordert eine Authentifizierung für lokale Produkte sowie für Dienste und Funktionen, die in der AWS-Cloud ausgeführt werden. **Topics** + [Authentifizierung für AWS-Cloud-Implementierungen](#aws-authentication) + [Authentifizierung für lokale Produkte](#authentication-on-prem) ## Authentifizierung für AWS-Cloud-Implementierungen SPEKE benötigt für die Verwendung mit einem Verschlüsseler eine AWS-Authentifizierung über IAM-Rollen. 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. Eine gängige Implementierung besteht darin, dass der Betreiber oder DRM-Plattformanbieter Amazon API Gateway vor dem Schlüsselanbieter verwendet und dann die AWS Identity and Access Management (AWS IAM) -Autorisierung für die API Gateway-Ressource aktiviert. 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 zur Erstellung einer Rolle finden Sie unter [AWS AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html). Weitere Informationen zum Signieren einer Anforderung finden Sie unter [AWS Sigv4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html). ## Authentifizierung für lokale Produkte Für lokale Produkte empfehlen wir die Verwendung SSL/TLS der Digest-Authentifizierung, um die beste Sicherheit zu gewährleisten. Sie sollten jedoch mindestens die Standardauthentifizierung über HTTPS verwenden. Beide Arten der Authentifizierung verwenden den Header `Authorization` in der HTTP-Anforderung: + **Digest-Authentifizierung** — Der Autorisierungsheader besteht aus der Kennung, `Digest` gefolgt von einer Reihe von Werten, die die Anfrage authentifizieren. Insbesondere wird ein Antwortwert durch eine Reihe von MD5 Hashfunktionen generiert, zu denen eine eindeutige one-time-use Nonce vom Server gehört, mit der sichergestellt wird, dass das Passwort sicher übertragen wird. + **Standardauthentifizierung** — Der Autorisierungsheader besteht aus der Kennung, `Basic` gefolgt von einer Base-64-kodierten Zeichenfolge, die den Benutzernamen und das Passwort 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)-Spezifikation [RFC 2617 – HTTP-Authentifizierung: Basis- und Digest-Zugriffsauthentifizierung](https://tools.ietf.org/html/rfc2617). # SPEKE API v1 Dies ist die REST-API für Secure Packager und Encoder Key Exchange (SPEKE) v1. Mit dieser Spezifizierung stellen Sie Kunden, die Verschlüsselung verwenden, DRM-Urheberrechtsschutz bereit. Um SPEKE-konform zu sein, muss Ihr DRM-Schlüsselanbieter die in dieser Spezifikation beschriebene REST-API verfügbar machen. Der Verschlüsseler führt API-Aufrufe Ihres Schlüsselanbieters durch. **Anmerkung** 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. SPEKE verwendet die Datenstrukturdefinition des DASH Industry Forum Content Protection Information Exchange Format (DASH-IF-CPIX) für den Schlüsselaustausch, mit einigen Einschränkungen. DASH-IF-CPIXdefiniert ein Schema, das einen erweiterbaren Multi-DRM-Austausch von der DRM-Plattform zum Verschlüsseler ermöglicht. 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. Ausführliche Informationen zum Austauschformat finden Sie in der CPIX-Spezifikation des DASH Industry Forum unter https://dashif. org/docs/DASH-IF-CPIX-v2-0.pdf. **Topics** + [SPEKE API v1 — Anpassungen und Einschränkungen der DASH-IF-Spezifikation](speke-constraints.md) + [SPEKE API v1 — Standard-Payload-Komponenten](standard-payload-components.md) + [SPEKE API v1 — Beispiele für Live-Workflow-Methodenaufrufe](live-workflow-methods.md) + [SPEKE API v1 — Beispiele für VOD-Workflow-Methodenaufrufe](vod-workflow-methods.md) + [SPEKE API v1 — Verschlüsselung von Inhaltsschlüsseln](content-key-encryption.md) + [SPEKE API v1 — Heartbeat](heartbeat.md) + [SPEKE API v1 — Überschreiben der Schlüssel-ID](kid-override.md) # SPEKE API v1 — Anpassungen und Einschränkungen der DASH-IF-Spezifikation Die DASH-IF CPIX-Spezifikation, https://dashif. org/docs/DASH-IF-CPIX-v2-0.pdf unterstützt eine Reihe von Anwendungsfällen und Topologien. Die SPEKE-API-Spezifikation entspricht der CPIX-Spezifikation mit den folgenden Anpassungen und Einschränkungen: + SPEKE folgt dem Encryptor Consumer-Workflow. + Für verschlüsselte Inhaltsschlüssel wendet SPEKE die folgenden Einschränkungen an: + SPEKE unterstützt keine Überprüfung digitaler Signaturen (XMLDSIG) für Payloads von Anfragen oder Antworten. + SPEKE benötigt 2048 RSA-basierte Zertifikate. + Für rotierende wichtige Workflows benötigt SPEKE den Filter,. `ContentKeyUsageRule` `KeyPeriodFilter` SPEKE ignoriert alle anderen Einstellungen. `ContentKeyUsageRule` + SPEKE lässt die Funktionalität weg. `UpdateHistoryItemList` Wenn die Liste in der Antwort vorhanden ist, ignoriert SPEKE sie. + SPEKE unterstützt die Schlüsselrotation. SPEKE verwendet nur `ContentKeyPeriod@index, um den Schlüsselzeitraum zu verfolgen. + Um MSS zu unterstützen PlayReady, verwendet SPEKE einen benutzerdefinierten Parameter unter dem `DRMSystem` Tag,. `SPEKE:ProtectionHeader` + 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 die HLS-Playlist stellt SPEKE unter dem `DRMSystem` Tag die optionalen benutzerdefinierten Parameter `speke:KeyFormat` und `speke:KeyFormatVersions` für die Werte des Tags `KEYFORMAT` und die `KEYFORMATVERSIONS` Parameter des Tags bereit. `EXT-X-KEY` 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 derzeit nicht mehrere Titel oder Keys pro Inhalt. Der SPEKE-konforme Verschlüsseler fungiert als Client und sendet `POST` Operationen 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-Payload-Komponenten 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: ![\[RequestIntroSimple\]](http://docs.aws.amazon.com/de_de/speke/latest/documentation/images/RequestIntroSimple.png) In der folgenden Tabelle werden die Hauptkomponenten für jedes `` aufgelistet. | Kennung | Description | | --- | --- | | `systemId` oder `schemeId` | Eindeutige ID für den Typ des DRM-Systems wie bei der DASH-IF-Organisation registriert. Eine Liste finden Sie unter [DASH-IF](https://dashif.org/identifiers/content_protection/) System. IDs | | `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. | \$1Beispielanfragen für Standardschlüssel und für PSSH \$1 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: ![\[RequestIntro1\]](http://docs.aws.amazon.com/de_de/speke/latest/documentation/images/RequestIntro1.png) \$1Beispielantworten für Standard Key und für PSSH \$1 Das folgende Beispiel zeigt die entsprechende Antwort des DRM-Schlüsselanbieters für den Verschlüsseler: ![\[ResponseIntro1\]](http://docs.aws.amazon.com/de_de/speke/latest/documentation/images/ResponseIntro1.png) # SPEKE API v1 — Beispiele für Live-Workflow-Methodenaufrufe *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. *Anforderungs-Header* | Name | Typ | Auftreten | Description | | --- | --- | --- | --- | | `AWS Authorization` | Zeichenfolge | 1..1 | Weitere Informationen finden Sie unter [AWS Sigv4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html). | | `X-Amz-Security-Token` | Zeichenfolge | 1..1 | Weitere Informationen finden Sie unter [AWS Sigv4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html). | | `X-Amz-Date` | Zeichenfolge | 1..1 | Weitere Informationen finden Sie unter [AWS Sigv4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html). | | `Content-Type` | Zeichenfolge | 1..1 | application/xml | *Antwort-Header* | Name | Typ | Auftreten | Description | | --- | --- | --- | --- | | `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 | Description | | --- | --- | --- | --- | | `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. | **Anmerkung** Die Beispiele in diesem Abschnitt zeigen keine Inhaltsschlüssel-Verschlüsselung. Informationen zum Hinzufügen von Inhaltsschlüsselverschlüsselung finden Sie unter [Inhaltsschlüsselverschlüsselung](content-key-encryption.md). *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: ``` ``` *Beispiel für eine Live-Antwortnutzlast mit entschlüsselten Schlüsseln* Das folgende Beispiel zeigt eine typische Antwortnutzlast des DRM-Schlüsselanbieters: ``` 5dGAgwGuUYu4dHeHtNlxJw== aHR0cHM6Ly83azR5dHV4cTVkLmV4ZWN1dGUtYXBpLnVzLXdlc3QtMi5hbWF6b25hd3MuY29tL0VrZVN0YWdlL2NsaWVudC9hYmMxMjMvOThlZTU1OTYtY2QzZS1hMjBkLTE2M2EtZTM4MjQyMGM2ZWZm aWRlbnRpdHk= MQ== aHR0cHM6Ly83azR5dHV4cTVkLmV4ZWN1dGUtYXBpLnVzLXdlc3QtMi5hbWF6b25hd3MuY29tL0VrZVN0YWdlL2NsaWVudC9hYmMxMjMvOThlZTU1OTYtY2QzZS1hMjBkLTE2M2EtZTM4MjQyMGM2ZWZm Y29tLmFwcGxlLnN0cmVhbWluZ2tleWRlbGl2ZXJ5 MQ== AAAAanBzc2gAAAAA7e+LqXnWSs6jyCfc1R0h7QAAAEoIARIQeSIcblaNbb7Dji6sAtKZzRoNd2lkZXZpbmVfdGVzdCIfa2V5LWlkOmVTSWNibGFOYmI3RGppNnNBdEtaelE9PSoCU0QyAA== CgMAAAEAAQAAAzwAVwBSAE0ASABFAEEARABFAFIAIAB4AG0AbABuAHMAPQAiAGgAdAB0AHAAOgAvAC8AcwBjAGgAZQBtAGEAcwAuAG0AaQBjAHIAbwBzAG8AZgB0AC4AYwBvAG0ALwBEAFIATQAvADIAMAAwADcALwAwADMALwBQAGwAYQB5AFIAZQBhAGQAeQBIAGUAYQBkAGUAcgAiACAAdgBlAHIAcwBpAG8AbgA9ACIANAAuADAALgAwAC4AMAAiAD4APABEAEEAVABBAD4APABQAFIATwBUAEUAQwBUAEkATgBGAE8APgA8AEsARQBZAEwARQBOAD4AMQA2ADwALwBLAEUAWQBMAEUATgA+ADwAQQBMAEcASQBEAD4AQQBFAFMAQwBUAFIAPAAvAEEATABHAEkARAA+ADwALwBQAFIATwBUAEUAQwBUAEkATgBGAE8APgA8AEsASQBEAD4ATwBXAGoAaAB0AHIAMwB1ADkAawArAHIAZABvADEASQBMAFkAMAByAGEAdwA9AD0APAAvAEsASQBEAD4APABDAEgARQBDAEsAUwBVAE0APgBCADMAQQA2AEEAMwB4AG0AdABkAEkAPQA8AC8AQwBIAEUAQwBLAFMAVQBNAD4APABMAEEAXwBVAFIATAA+AGgAdAB0AHAAOgAvAC8AcABsAGEAeQByAGUAYQBkAHkALgBkAGkAcgBlAGMAdAB0AGEAcABzAC4AbgBlAHQALwBwAHIALwBzAHYAYwAvAHIAaQBnAGgAdABzAG0AYQBuAGEAZwBlAHIALgBhAHMAbQB4AD8AUABsAGEAeQBSAGkAZwBoAHQAPQAxACYAYQBtAHAAOwBhAG0AcAA7AGEAbQBwADsAVQBzAGUAUwBpAG0AcABsAGUATgBvAG4AUABlAHIAcwBpAHMAdABlAG4AdABMAGkAYwBlAG4AcwBlAD0AMQA8AC8ATABBAF8AVQBSAEwAPgA8AC8ARABBAFQAQQA+ADwALwBXAFIATQBIAEUAQQBEAEUAUgA+AA== AAADMHBzc2gAAAAAmgTweZhAQoarkuZb4IhflQAAAxAQAwAAAQABAAYDPABXAFIATQBIAEUAQQBEAEUAUgAgAHgAbQBsAG4AcwA9ACIAaAB0AHQAcAA6AC8ALwBzAGMAaABlAG0AYQBzAC4AbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQAvAEQAUgBNAC8AMgAwADAANwAvADAAMwAvAFAAbABhAHkAUgBlAGEAZAB5AEgAZQBhAGQAZQByACIAIAB2AGUAcgBzAGkAbwBuAD0AIgA0AC4AMAAuADAALgAwACIAPgA8AEQAQQBUAEEAPgA8AFAAUgBPAFQARQBDAFQASQBOAEYATwA+ADwASwBFAFkATABFAE4APgAxADYAPAAvAEsARQBZAEwARQBOAD4APABBAEwARwBJAEQAPgBBAEUAUwBDAFQAUgA8AC8AQQBMAEcASQBEAD4APAAvAFAAUgBPAFQARQBDAFQASQBOAEYATwA+ADwASwBJAEQAPgBiAGgAdwBpAGUAWQAxAFcAdgBtADMARABqAGkANgBzAEEAdABLAFoAegBRAD0APQA8AC8ASwBJAEQAPgA8AEMASABFAEMASwBTAFUATQA+AGEAVABtAFAASgBWAEMAVgBaADYAcwA9ADwALwBDAEgARQBDAEsAUwBVAE0APgA8AEwAQQBfAFUAUgBMAD4AaAB0AHQAcABzADoALwAvAHAAcgBsAHMALgBhAHQAdgAtAHAAcwAuAGEAbQBhAHoAbwBuAC4AYwBvAG0ALwBjAGQAcAA8AC8ATABBAF8AVQBSAEwAPgA8AEMAVQBTAFQATwBNAEEAVABUAFIASQBCAFUAVABFAFMAPgA8AEkASQBTAF8ARABSAE0AXwBWAEUAUgBTAEkATwBOAD4ANwAuADEALgAxADQAMwA5AC4AMAA8AC8ASQBJAFMAXwBEAFIATQBfAFYARQBSAFMASQBPAE4APgA8AC8AQwBVAFMAVABPAE0AQQBUAFQAUgBJAEIAVQBUAEUAUwA+ADwALwBEAEEAVABBAD4APAAvAFcAUgBNAEgARQBBAEQARQBSAD4A ``` # SPEKE API v1 — Beispiele für VOD-Workflow-Methodenaufrufe *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. *Antwort-Header* | Name | Typ | Auftreten | Description | | --- | --- | --- | --- | | `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 | Description | | --- | --- | --- | --- | | `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. | **Anmerkung** Die Beispiele in diesem Abschnitt zeigen keine Inhaltsschlüssel-Verschlüsselung. Informationen zum Hinzufügen von Inhaltsschlüsselverschlüsselung finden Sie unter [Inhaltsschlüsselverschlüsselung](content-key-encryption.md). *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: ``` ``` *Beispiel für eine VOD-Antwortnutzlast mit entschlüsselten Schlüsseln* Das folgende Beispiel zeigt eine grundlegende VOD-Antwortnutzlast des DRM-Schlüsselanbieters: ``` 5dGAgwGuUYu4dHeHtNlxJw== aHR0cHM6Ly83azR5dHV4cTVkLmV4ZWN1dGUtYXBpLnVzLXdlc3QtMi5hbWF6b25hd3MuY29tL0VrZVN0YWdlL2NsaWVudC9hYmMxMjMvOThlZTU1OTYtY2QzZS1hMjBkLTE2M2EtZTM4MjQyMGM2ZWZm aWRlbnRpdHk= MQ== aHR0cHM6Ly83azR5dHV4cTVkLmV4ZWN1dGUtYXBpLnVzLXdlc3QtMi5hbWF6b25hd3MuY29tL0VrZVN0YWdlL2NsaWVudC9hYmMxMjMvOThlZTU1OTYtY2QzZS1hMjBkLTE2M2EtZTM4MjQyMGM2ZWZm Y29tLmFwcGxlLnN0cmVhbWluZ2tleWRlbGl2ZXJ5 MQ== AAAAanBzc2gAAAAA7e+LqXnWSs6jyCfc1R0h7QAAAEoIARIQeSIcblaNbb7Dji6sAtKZzRoNd2lkZXZpbmVfdGVzdCIfa2V5LWlkOmVTSWNibGFOYmI3RGppNnNBdEtaelE9PSoCU0QyAA== CgMAAAEAAQAAAzwAVwBSAE0ASABFAEEARABFAFIAIAB4AG0AbABuAHMAPQAiAGgAdAB0AHAAOgAvAC8AcwBjAGgAZQBtAGEAcwAuAG0AaQBjAHIAbwBzAG8AZgB0AC4AYwBvAG0ALwBEAFIATQAvADIAMAAwADcALwAwADMALwBQAGwAYQB5AFIAZQBhAGQAeQBIAGUAYQBkAGUAcgAiACAAdgBlAHIAcwBpAG8AbgA9ACIANAAuADAALgAwAC4AMAAiAD4APABEAEEAVABBAD4APABQAFIATwBUAEUAQwBUAEkATgBGAE8APgA8AEsARQBZAEwARQBOAD4AMQA2ADwALwBLAEUAWQBMAEUATgA+ADwAQQBMAEcASQBEAD4AQQBFAFMAQwBUAFIAPAAvAEEATABHAEkARAA+ADwALwBQAFIATwBUAEUAQwBUAEkATgBGAE8APgA8AEsASQBEAD4ATwBXAGoAaAB0AHIAMwB1ADkAawArAHIAZABvADEASQBMAFkAMAByAGEAdwA9AD0APAAvAEsASQBEAD4APABDAEgARQBDAEsAUwBVAE0APgBCADMAQQA2AEEAMwB4AG0AdABkAEkAPQA8AC8AQwBIAEUAQwBLAFMAVQBNAD4APABMAEEAXwBVAFIATAA+AGgAdAB0AHAAOgAvAC8AcABsAGEAeQByAGUAYQBkAHkALgBkAGkAcgBlAGMAdAB0AGEAcABzAC4AbgBlAHQALwBwAHIALwBzAHYAYwAvAHIAaQBnAGgAdABzAG0AYQBuAGEAZwBlAHIALgBhAHMAbQB4AD8AUABsAGEAeQBSAGkAZwBoAHQAPQAxACYAYQBtAHAAOwBhAG0AcAA7AGEAbQBwADsAVQBzAGUAUwBpAG0AcABsAGUATgBvAG4AUABlAHIAcwBpAHMAdABlAG4AdABMAGkAYwBlAG4AcwBlAD0AMQA8AC8ATABBAF8AVQBSAEwAPgA8AC8ARABBAFQAQQA+ADwALwBXAFIATQBIAEUAQQBEAEUAUgA+AA== AAADMHBzc2gAAAAAmgTweZhAQoarkuZb4IhflQAAAxAQAwAAAQABAAYDPABXAFIATQBIAEUAQQBEAEUAUgAgAHgAbQBsAG4AcwA9ACIAaAB0AHQAcAA6AC8ALwBzAGMAaABlAG0AYQBzAC4AbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQAvAEQAUgBNAC8AMgAwADAANwAvADAAMwAvAFAAbABhAHkAUgBlAGEAZAB5AEgAZQBhAGQAZQByACIAIAB2AGUAcgBzAGkAbwBuAD0AIgA0AC4AMAAuADAALgAwACIAPgA8AEQAQQBUAEEAPgA8AFAAUgBPAFQARQBDAFQASQBOAEYATwA+ADwASwBFAFkATABFAE4APgAxADYAPAAvAEsARQBZAEwARQBOAD4APABBAEwARwBJAEQAPgBBAEUAUwBDAFQAUgA8AC8AQQBMAEcASQBEAD4APAAvAFAAUgBPAFQARQBDAFQASQBOAEYATwA+ADwASwBJAEQAPgBiAGgAdwBpAGUAWQAxAFcAdgBtADMARABqAGkANgBzAEEAdABLAFoAegBRAD0APQA8AC8ASwBJAEQAPgA8AEMASABFAEMASwBTAFUATQA+AGEAVABtAFAASgBWAEMAVgBaADYAcwA9ADwALwBDAEgARQBDAEsAUwBVAE0APgA8AEwAQQBfAFUAUgBMAD4AaAB0AHQAcABzADoALwAvAHAAcgBsAHMALgBhAHQAdgAtAHAAcwAuAGEAbQBhAHoAbwBuAC4AYwBvAG0ALwBjAGQAcAA8AC8ATABBAF8AVQBSAEwAPgA8AEMAVQBTAFQATwBNAEEAVABUAFIASQBCAFUAVABFAFMAPgA8AEkASQBTAF8ARABSAE0AXwBWAEUAUgBTAEkATwBOAD4ANwAuADEALgAxADQAMwA5AC4AMAA8AC8ASQBJAFMAXwBEAFIATQBfAFYARQBSAFMASQBPAE4APgA8AC8AQwBVAFMAVABPAE0AQQBUAFQAUgBJAEIAVQBUAEUAUwA+ADwALwBEAEEAVABBAD4APAAvAFcAUgBNAEgARQBBAEQARQBSAD4A ``` # SPEKE API v1 — Verschlüsselung von Inhaltsschlüsseln Sie können Ihrer SPEKE-Implementierung optional eine Inhaltsschlüsselverschlüsselung hinzufügen. Die Inhaltsschlüsselverschlüsselung garantiert vollständigen end-to-end Schutz, indem sie zusätzlich zur Verschlüsselung des Inhalts selbst auch die Inhaltsschlüssel für die Übertragung verschlüsselt. Wenn Sie dies nicht für Ihren Schlüsselanbieter implementieren, verlassen Sie sich aus Sicherheitsgründen auf die Verschlüsselung der Transportschicht sowie auf eine starke Authentifizierung. Um die Inhaltsschlüsselverschlüsselung für Verschlüsseler zu verwenden, die in der AWS-Cloud ausgeführt werden, importieren Kunden Zertifikate in den AWS Certificate Manager und verwenden das resultierende Zertifikat dann ARNs für ihre Verschlüsselungsaktivitäten. Der Verschlüsseler verwendet das Zertifikat ARNs und den ACM-Service, um dem DRM-Schlüsselanbieter verschlüsselte Inhaltsschlüssel bereitzustellen. **Einschränkungen** SPEKE unterstützt die Verschlüsselung von Inhaltsschlüsseln gemäß der DASH-IF CPIX-Spezifikation mit den folgenden Einschränkungen: + SPEKE unterstützt keine Überprüfung digitaler Signaturen (XMLDSIG) für Payloads von Anfragen oder Antworten. + SPEKE benötigt 2048 RSA-basierte Zertifikate. Diese Einschränkungen sind auch unter [Anpassungen und Einschränkungen der DASH-IF-Spezifikation](speke-constraints.md) aufgeführt. **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](https://dashif.org/docs/DASH-IF-CPIX-v2-0.pdf). *Beispiel für das Inhaltsschlüssel-Verschlüsselungselement ` ` in der Anforderungsnutzlast* 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= 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 — Heartbeat *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)* | HTTP-CODE | Name der Nutzlast | Auftreten | Description | | --- | --- | --- | --- | | `200 (Success)` | Statusmeldung | 1..1 | Eine Nachricht, die den Status beschreibt. | # SPEKE API v1 — Überschreiben der Schlüssel-ID 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+LqXnWSs6jyCfc1R0h7QAAAEoIARIQeSIcblaNbb7Dji6sAtKZzRoNd2lkZXZpbmVfdGVzdCIfa2V5LWlkOmVTSWNibGFOYmI3RGppNnNBdEtaelE9PSoCU0QyAA== ``` # SPEKE API v2 Dies ist die REST-API für Secure Packager und Encoder Key Exchange (SPEKE) v2. Mit dieser Spezifizierung stellen Sie Kunden, die Verschlüsselung verwenden, DRM-Urheberrechtsschutz bereit. Um SPEKE-konform zu sein, muss Ihr DRM-Schlüsselanbieter die in dieser Spezifikation beschriebene REST-API verfügbar machen. Der Verschlüsseler führt API-Aufrufe Ihres Schlüsselanbieters durch. **Anmerkung** 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. SPEKE verwendet die Datenstrukturdefinition des DASH Industry Forum Content Protection Information Exchange Format (DASH-IF-CPIX) für den Schlüsselaustausch, mit einigen Einschränkungen. DASH-IF-CPIXdefiniert ein Schema, das einen erweiterbaren Multi-DRM-Austausch von der DRM-Plattform zum Verschlüsseler ermöglicht. 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. Ab der Version 2.0 ist SPEKE auf eine bestimmte CPIX-Version ausgerichtet: Auf der SPEKE-Seite wird dies durch die Verwendung des `X-Speke-Version` HTTP-Headers und auf der CPIX-Seite durch die Verwendung des Attributs erzwungen. `CPIX@version` Das Fehlen dieser Elemente in den Anfragen ist typisch für ältere SPEKE v1-Workflows. In SPEKE v2-Workflows wird erwartet, dass der Schlüsselanbieter CPIX-Dokumente nur verarbeitet, wenn er beide Versionsparameter unterstützt. Detaillierte Informationen zum Austauschformat finden Sie in der [CPIX](https://dashif.org/docs/CPIX2.3/Cpix.html) 2.3-Spezifikation des DASH Industry Forum. Insgesamt bringt SPEKE v2.0 im Vergleich zu SPEKE v1.0 die folgenden Weiterentwicklungen: + Alle Tags aus dem SPEKE-XML-Namespace sind zugunsten gleichwertiger Tags im CPIX-XML-Namespace veraltet + `SPEKE:ProtectionHeader`ist veraltet und wird ersetzt durch `CPIX:DRMSystem.SmoothStreamingProtectionHeaderData` + `CPIX:URIExtXKey`, `SPEKE:KeyFormat` und `SPEKE:KeyFormatVersions` sind veraltet und wurden ersetzt durch `CPIX:DRMSystem.HLSSignalingData` + `CPIX@id`wird ersetzt durch `CPIX@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 der HTTP-Header: neuer Header, Header umbenannt in `X-Speke-Version` `Speke-User-Agent` `X-Speke-User-Agent` + Veraltete Heartbeat-API Da die SPEKE v1.0-Spezifikation unverändert bleibt, müssen bestehende Implementierungen nicht geändert werden, um SPEKE v1.0-Workflows weiterhin zu unterstützen. **Topics** + [SPEKE API v2 — Anpassungen und Einschränkungen der DASH-IF-Spezifikation](speke-constraints-v2.md) + [SPEKE API v2 — Standard-Payload-Komponenten](standard-payload-components-v2.md) + [SPEKE API v2 - Verschlüsselungsvertrag](encryption-contract-v2.md) + [SPEKE API v2 — Beispiele für Live-Workflow-Methodenaufrufe](live-workflow-methods-v2.md) + [SPEKE API v2 — Beispiele für VOD-Workflow-Methodenaufrufe](vod-workflow-method-v2.md) + [SPEKE API v2 — Verschlüsselung von Inhaltsschlüsseln](content-key-encryption-v2.md) + [SPEKE API v2 — Überschreiben der Schlüssel-ID](kid-override-v2.md) # SPEKE API v2 — Anpassungen und Einschränkungen der DASH-IF-Spezifikation Die [CPIX 2.3-Spezifikation](https://dashif.org/docs/CPIX2.3/Cpix.html) des DASH Industry Forum unterstützt eine Reihe von Anwendungsfällen und Topologien. Die SPEKE API v2.0-Spezifikation definiert sowohl ein CPIX-Profil als auch eine API für CPIX. Um diese beiden Ziele zu erreichen, hält sie sich an die CPIX-Spezifikation mit den folgenden Anpassungen und Einschränkungen: **CPIX-Profil** + SPEKE folgt dem Encryptor Consumer-Workflow. + Für verschlüsselte Inhaltsschlüssel wendet SPEKE die folgenden Einschränkungen an: + SPEKE unterstützt keine Überprüfung digitaler Signaturen (XMLDSIG) für Payloads von Anfragen oder Antworten. + SPEKE benötigt 2048 RSA-basierte Zertifikate. + SPEKE nutzt nur einen Teil der CPIX-Funktionen: + SPEKE lässt die Funktionalität weg. `UpdateHistoryItemList` Wenn die Liste in der Antwort vorhanden ist, ignoriert SPEKE sie. + SPEKE lässt die wichtigsten Funktionen aus. root/leaf Wenn das `ContentKey@dependsOnKey` Attribut in der Antwort vorhanden ist, ignoriert SPEKE es. + SPEKE lässt das `BitrateFilter` Element und das Attribut weg. `VideoFilter@wcg` Wenn diese Elemente oder Attribute in der CPIX-Nutzlast vorhanden sind, ignoriert SPEKE sie. + Nur die Elemente oder Attribute, auf die auf der Seite [Standard-Payload-Komponenten oder der Seite](standard-payload-components-v2.md) mit dem [Verschlüsselungsvertrag](encryption-contract-v2.md) als „Unterstützt“ verwiesen wird, können in CPIX-Dokumenten verwendet werden, die mit SPEKE v2 ausgetauscht werden. + Wenn sie vom Verschlüsseler in einer CPIX-Anfrage enthalten sind, müssen alle Elemente und Attribute in der CPIX-Antwort des Schlüsselanbieters einen gültigen Wert enthalten. Wenn nicht, stoppt der Verschlüsseler und gibt einen Fehler aus. + SPEKE unterstützt die Schlüsselrotation mit `KeyPeriodFilter` Elementen. SPEKE verwendet nur die`ContentKeyPeriod@index`, um den Schlüsselzeitraum zu verfolgen. + Für die HLS-Signalisierung müssen mehrere `DRMSystem.HLSSignalingData` Elemente verwendet werden: eines mit dem `DRMSystem.HLSSignalingData@playlist` Attributwert „media“ und eines mit dem `DRMSystem.HLSSignalingData@playlist` Attributwert „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. + Der Verschlüsseler muss einen Wert für das Attribut enthalten. `CPIX@contentId` Wenn der Schlüsselanbieter einen leeren Wert für dieses Attribut erhält, gibt er einen Fehler mit der Beschreibung „Missing CPIX @contentId“ zurück. `CPIX@contentId`Der Wert kann vom Schlüsselanbieter nicht überschrieben werden. `CPIX@id`Wert, falls nicht Null, muss vom Schlüsselanbieter ignoriert werden. + Der Verschlüsseler muss einen Wert für das `CPIX@version` Attribut enthalten. Wenn der Schlüsselanbieter einen leeren Wert für dieses Attribut erhält, gibt er einen Fehler mit der Beschreibung „Missing CPIX @version“ zurück. Wenn eine Anfrage mit einer nicht unterstützten Version empfangen wird, muss die vom Schlüsselanbieter zurückgegebene Fehlerbeschreibung „Unsupported CPIX @version“ lauten. `CPIX@version`Der Wert kann vom Schlüsselanbieter nicht überschrieben werden. + Der Verschlüsseler muss für jeden angeforderten Schlüssel einen Wert für das `ContentKey@commonEncryptionScheme` Attribut angeben. Wenn der Schlüsselanbieter einen leeren Wert für dieses Attribut erhält, gibt er einen Fehler mit der Beschreibung „Missing ContentKey @ commonEncryptionScheme for KID`id`“ zurück. Ein einzelnes CPIX-Dokument kann nicht mehrere Werte für verschiedene Attribute kombinieren. `ContentKey@commonEncryptionScheme` Beim Empfang einer solchen Kombination gibt der Schlüsselanbieter einen Fehler mit der Beschreibung „Nicht konforme ContentKey @-Kombination“ zurück. commonEncryptionScheme Nicht alle `ContentKey@commonEncryptionScheme` Werte sind mit allen DRM-Technologien kompatibel. Beim Empfang einer solchen Kombination gibt der Schlüsselanbieter einen Fehler mit der Beschreibung „ContentKey@ commonEncryptionScheme nicht kompatibel mit DRMSystem `id`“ zurück. `ContentKey@commonEncryptionScheme`Der Wert kann vom Schlüsselanbieter nicht überschrieben werden. + Beim Empfang verschiedener Werte für ein `DRMSystem.ContentProtectionData` `` InnerXML-Element im CPIX-Antworttext stoppt der Verschlüsseler `DRMSystem@PSSH` und gibt einen Fehler aus. **API für CPIX** + Der Schlüsselanbieter muss einen Wert für den `X-Speke-User-Agent` HTTP-Antwort-Header angeben. + Ein SPEKE-kompatibler Verschlüsseler fungiert als Client und sendet POST-Operationen an den Endpunkt des Schlüsselanbieters. + Der Verschlüsseler muss einen Wert für den `X-Speke-Version` HTTP-Anforderungsheader enthalten, wobei die SPEKE-Version, die bei der Anfrage verwendet wurde, formuliert ist als. MajorVersion MinorVersion, wie '2.0' für SPEKE v2.0. Wenn der Schlüsselanbieter die vom Verschlüsseler für die aktuelle Anfrage verwendete SPEKE-Version nicht unterstützt, gibt der Schlüsselanbieter einen Fehler mit der Beschreibung „SPEKE-Version nicht unterstützt“ zurück und versucht nicht, das CPIX-Dokument nach bestem Wissen zu verarbeiten. Der vom Verschlüsseler definierte `X-Speke-Version` Header-Wert kann vom Schlüsselanbieter in der Antwort auf die Anfrage nicht geändert werden. + Beim Empfang von Fehlern im Antworttext gibt der Verschlüsseler einen Fehler aus und versucht die Anfrage nicht erneut mit einer SPEKE v1.0-Version. Wenn der Schlüsselanbieter keinen Fehler zurückgibt, aber kein CPIX-Dokument zurückgibt, das die obligatorischen Informationen enthält, sollte der Verschlüsseler den Vorgang beenden und einen Fehler ausgeben. In der folgenden Tabelle sind die Standardnachrichten zusammengefasst, die vom Schlüsselanbieter im Hauptteil der Nachricht zurückgegeben werden müssen. Der HTTP-Antwortcode muss in Fehlerfällen ein 4XX oder ein 5XX sein, niemals ein 200. Der 422-Fehlercode kann für alle Fehler im Zusammenhang mit SPEKE/CPIX verwendet werden. | Fehlerfall | Fehlermeldung | | --- | --- | | CPIX @contentId ist nicht definiert | CPIX @contentId fehlt | | CPIX @version ist nicht definiert | CPIX @version fehlt | | CPIX @version wird nicht unterstützt | CPIX @version wird nicht unterstützt | | ContentKey@ commonEncryptionScheme ist nicht definiert | ContentKey@ commonEncryptionScheme für KID fehlt `id` (wo dem Wert ContentKey @kid `id` entspricht) | | In einem einzigen CPIX-Dokument werden mehrere ContentKey commonEncryptionScheme @-Werte verwendet | Nicht konforme @-Kombination ContentKey commonEncryptionScheme | | ContentKey@ commonEncryptionScheme ist nicht mit der DRM-Technologie kompatibel | ContentKey@ ist commonEncryptionScheme nicht kompatibel mit DRMSystem `id` (wo dem `id` Wert DRMSystem @systemId entspricht) | | X-Speke-Version Der Header-Wert ist keine unterstützte SPEKE-Version | SPEKE-Version wird nicht unterstützt | | Der Verschlüsselungsvertrag ist falsch formatiert | Fehlerhafter Verschlüsselungsvertrag | | Der Verschlüsselungsvertrag widerspricht den Einschränkungen der DRM-Sicherheitsstufen | Der angeforderte CPIX-Verschlüsselungsvertrag wird nicht unterstützt | | Der Verschlüsselungsvertrag enthält keine OE-Elemente VideoFilter AudioFilter | Fehlender CPIX-Verschlüsselungsvertrag | # SPEKE API v2 — Standard-Payload-Komponenten Durch eine einzige SPEKE-Anfrage kann der Verschlüsseler mehrere Inhaltsschlüssel zusammen mit der erforderlichen Manifestsignalisierung für mehrere Verpackungsformate anfordern, je nach dem Verschlüsselungsvertrag, der für einen bestimmten Inhalt definiert ist. Um all diese Aspekte abzudecken, besteht ein Standard-CPIX-Dokument aus drei obligatorischen Listenabschnitten sowie einem optionalen Listenabschnitt für die Schlüsselrotation bei Live-Inhalten. ** Abschnitt und Element der obersten Ebene** Dies ist ein obligatorischer Abschnitt, der sowohl für Live- als auch für VOD-Streaming relevant ist und die verschiedenen Inhaltsschlüssel definiert, die vom Verschlüsseler verwendet werden müssen. Das `` Element kann ein oder mehrere `` untergeordnete Elemente enthalten, von denen jedes einen eigenen Inhaltsschlüssel beschreibt. Gemäß der CPIX-Spezifikation sind die möglichen Werte des `ContentKey@commonEncryptionScheme` Attributs in der Spezifikation Common Encryption in ISO-Basisdateien für Mediendateien (ISO/IEC 23001-7:2016) definiert: + 'cenc': Verschlüsselung von Vollproben im AES-CTR-Modus und Video-NAL-Untermusterverschlüsselung + 'cbc1': AES-CBC-Modus für vollständige Stichproben und Video-NAL-Teilmusterverschlüsselung + 'cens': Partielle Video-NAL-Musterverschlüsselung im AES-CTR-Modus + 'cbcs': Partielle Video-NAL-Musterverschlüsselung im AES-CBC-Modus Das folgende Beispiel zeigt ein CPIX-Dokument mit einem einzigen, unverschlüsselten Inhaltsschlüssel: ``` 5dGAgwGuUYu4dHeHtNlxJw== ... ``` Standardmäßig sind Inhaltsschlüssel nicht verschlüsselt, wie im Beispiel unten. Die Verschlüsselung von Inhaltsschlüsseln kann jedoch vom Verschlüsseler mithilfe des Elements angefordert werden. DeliveryDataList Weitere Informationen finden Sie im Abschnitt Verschlüsselung von Inhaltsschlüsseln. | Element, das von SPEKE unterstützt wird | Obligatorische Attribute | Optionale Attribute | Obligatorische untergeordnete Elemente | Optionale untergeordnete Elemente | | --- | --- | --- | --- | --- | | | Inhalts-ID, Version, xmlns: cpix, xmlns: pskc | name, xmlns:enc | eins , eins, eins DRMSystemContentKeyUsageRuleList | ein , eins | | | - | id | mindestens ein ContentKey | - | | ContentKey | Kind, Data commonEncryptionScheme | id, Algorithmus, explizitiv | eins | - | | | PlainValue oder EncryptedValue | Wert MAC | - | , CipherData | **Abschnitt DRMSystem** Dies ist ein obligatorischer Abschnitt, der sowohl für Live- als auch für VOD-Streaming relevant ist und in dem die verschiedenen DRM-Systeme definiert werden, die zusammen mit den Inhaltsschlüsseln genutzt werden müssen. Das folgende Beispiel zeigt eine DRM-Systemliste mit einer einzigen PlayReady DRM-Systemspezifikation: ``` HicXmbZ2m[...]4== HicXmbZ2m[...]jEi t7WwH24FI[...]YCC FFFFanBzc[...]A== s5RrJ12HL[...]UBB ``` Eine vollständige Liste der DRM-Systeme IDs finden Sie im [Abschnitt Content Protection](https://dashif.org/identifiers/content_protection/) des DASH-IF Identifiers-Repositorys. | Element, das von SPEKE unterstützt wird | Obligatorische Attribute | Optionale Attribute | Obligatorische untergeordnete Elemente | Optionale untergeordnete Elemente | | --- | --- | --- | --- | --- | | DRMSystem | - | id | mindestens ein DRMSystem | - | | DRMSystem | Kind, SystemID | ID, Name, PSSH | - | ContentProtectionData, SmoothStreamingProtectionHeaderData, zwei -Elemente mit unterschiedlichen Playlist-Attributwerten | `DRMSystem@PSSH`ist obligatorisch, wenn die ISO-BMFF-Kapselung auf Mediensegmente angewendet wird. `DRMSystem.ContentProtectionData`Das `` InnerXML-Element wird vom Verschlüsseler nur für manifeste Signalzwecke genutzt. Wenn vorhanden `DRMSystem@PSSH` ist und ein `` InnerXML-Element `DRMSystem.ContentProtectionData` enthält, müssen beide Werte identisch sein. Wenn die `DRMSystem` Signalisierung in HLS-Manifesten erfolgen soll, müssen sowohl a `` - als auch `` a-Elemente in der CPIX-Anfrage und -Antwort enthalten sein. **Abschnitt ContentKeyPeriodList** Dies ist ein optionaler Abschnitt, der nur für Live-Streaming relevant ist und in dem die Krypto-Perioden definiert werden, die auf den Inhalt angewendet werden. Das `` Element kann ein oder mehrere `` untergeordnete Elemente enthalten, von denen jedes eine bestimmte Krypto-Periode in der Live-Timeline beschreibt. Die Verwendung UUIDs als Teil des Werts des ID-Attributs ist ein häufig verwendeter Ansatz. ``` ``` | Element, das von SPEKE unterstützt wird | Obligatorische Attribute | Optionale Attribute | Obligatorische untergeordnete Elemente | Optionale untergeordnete Elemente | | --- | --- | --- | --- | --- | | ContentKeyPeriodList | - | id | mindestens ein ContentKeyPeriod | - | | ContentKeyPeriod | ID, Index | - | - | - | Wenn Kryptoperioden verwendet werden, müssen die Verschlüsselungsschlüssel auch an eine der Kryptoperioden im CPIX-Dokument angehängt werden, wie im folgenden Abschnitt gezeigt. **Abschnitt ContentKeyUsageRuleList** Dies ist ein obligatorischer Abschnitt, der sowohl für Live- als auch für VOD-Streaming relevant ist und definiert, wie die verschiedenen Inhaltsschlüssel Tracks innerhalb des Streamsets und während der Krypto-Perioden schützen. Das -Element kann ein oder mehrere untergeordnete -Elemente enthalten, von denen jedes die Spuren beschreibt, auf die der Verschlüsseler einen bestimmten Inhaltsschlüssel angewendet hat, möglicherweise während einer bestimmten Kryptoperiode. In einem -Element muss mindestens ein - oder ein -Element vorhanden sein. ContentKeyUsageRule Das folgende Beispiel zeigt eine einfache Liste mit nur einer Regel, die einen einzigen Inhaltsschlüssel auf alle Audio- und Videotracks während einer bestimmten Kryptoperiode anwendet. ``` ``` | Element, das von SPEKE unterstützt wird | Obligatorische Attribute | Optionale Attribute | Obligatorische untergeordnete Elemente | Optionale untergeordnete Elemente | | --- | --- | --- | --- | --- | | ContentKeyUsageRuleList | - | id | mindestens ein ContentKeyUsageRule | - | | ContentKeyUsageRule | Kind, intendedTrackType | - | mindestens ein oder ein (\$1) VideoFilter | KeyPeriodFilter | | KeyPeriodFilter | Perioden-ID | - | - | - | | AudioFilter | - | MinChannels, MaxChannels | - | - | | VideoFilter | - | MinPixels, MaxPixels, hdr, MinFPS, MaxFPS | - | - | *[(\$1) Eine ausführliche Erklärung zur Verwendung einzelner oder mehrerer Inhaltsschlüssel zum Schutz eines oder mehrerer Tracks in einem Streamset finden Sie in der Dokumentation zum Verschlüsselungsvertrag.](encryption-contract-v2.md) \$1* # SPEKE API v2 - Verschlüsselungsvertrag Der Verschlüsselungsvertrag legt auf der Grundlage der Eigenschaften der Tracks fest, welche Inhaltsschlüssel welche Tracks innerhalb eines bestimmten Streamsets schützen. Die Verwendung mehrerer Inhaltsschlüssel für verschiedene Titel in einem Streamset ist zwar eine in der Branche empfohlene bewährte Methode, ist aber nicht verpflichtend, wird aber empfohlen — mindestens zwei verschiedene Inhaltsschlüssel, einer für Audiotracks und einer für Videotracks. Die Verwendung eines einzigen Inhaltsschlüssels zur Verschlüsselung mehrerer Titel ist möglich, muss aber in dem vom Verschlüsseler an den Schlüsselanbieter gesendeten CPIX-Dokument explizit signalisiert werden. Im Allgemeinen beschreibt der Verschlüsseler immer genau, wie viele Inhaltsschlüssel benötigt werden und wie sie zur Verschlüsselung der verschiedenen Medientracks genutzt werden. **Prinzipien** Der Verschlüsselungsvertrag befindet sich im `` Abschnitt des CPIX-Dokuments. In diesem Abschnitt entspricht jeder in diesem `` Abschnitt definierte Inhaltsschlüssel einem bestimmten `` Element, das Folgendes beinhalten muss: + ein `ContentKeyUsageRule@intendedTrackType` Attribut, das auf eine oder mehrere Unterkomponenten verweisen kann, getrennt durch das Zeichen „\$1“, wenn mehrere Unterkomponenten verwendet werden. Der Wert von `ContentKeyUsageRule@intendedTrackType` muss in einem Verschlüsselungsvertrag einmalig sein und kann nicht in mehreren `ContentKeyUsageRule` Elementen verwendet werden. + ein oder mehrere `` oder `` untergeordnete Elemente, abhängig vom Wert des `ContentKeyUsageRule@intendedTrackType` Attributs. Für diese Beziehung gelten die folgenden Regeln: + Wenn alle Audio- und Videotracks des Streamsets mit einem eindeutigen Inhaltsschlüssel geschützt werden müssen, `'ALL'` muss die Zeichenfolge als `ContentKeyUsageRule@intendedTrackType` Attributwert verwendet werden. Beispiel 1 zeigt einen solchen Anwendungsfall. In dieser Situation müssen `` sowohl ein als auch ein `` untergeordnetes Element ohne Attribut enthalten sein. Jede andere Kombination von `` and/or `` Elementen ist in diesem speziellen Kontext ungültig. + Für alle anderen Anwendungsfälle kann der Wert des `ContentKeyUsageRule@intendedTrackType` Attributs frei definiert werden, und die Anzahl der `` `` untergeordneten Elemente muss der Anzahl der Unterkomponenten entsprechen, die durch das Pluszeichen aggregiert werden. Die Beispiele 2/3/4/5/6/7/9/10 veranschaulichen diese Anforderung, wenn eine einzelne Unterkomponente im Attributwert vorhanden ist. `ContentKeyUsageRule@intendedTrackType` Beispiel 8 verdeutlicht die Verwendung mehrerer Unterkomponenten: `ContentKeyUsageRule@intendedTrackType="SD+HD"` wird durch zwei unterschiedliche `` untergeordnete Elemente mit unterschiedlichen Attributwerten beschrieben und `ContentKeyUsageRule@intendedTrackType="HDR+HFR+UHD"` wird durch drei unterschiedliche untergeordnete Elemente mit unterschiedlichen Attributwerten beschrieben. `` **Filter** CPIX definiert mehrere Filterelemente und Attribute, aber SPEKE unterstützt nur eine Teilmenge davon. Die folgende Tabelle fasst diese Unterschiede zusammen: | CPIX-Filtertyp | Allgemeine SPEKE-Unterstützung | Von SPEKE unterstützte Filterattribute | Filterattribute werden von SPEKE nicht unterstützt | | --- | --- | --- | --- | | VideoFilter | Ja | minPixels, maxPixels, hdr, minFps, maxFPS (optionale Attribute) | wcg | | AudioFilter | Ja | minChannels, maxChannels (optionale Attribute) | | | KeyPeriodFilter | Ja | PeriodID (obligatorisches Attribut) | | | BitrateFilter | Nein | – | – | | LabelFilter | Nein | – | – | Gemäß der CPIX-Spezifikation für ist [minPixels VideoFilter, maxPixels] ein All-Inclusive-Bereich in beiden Dimensionen, während (minFPS, maxFPS] nur für die maxFPS-Dimension inklusiv ist. Denn [minChannels AudioFilter, maxChannels] ist ein inklusiver Bereich in beiden Dimensionen. **Problematische Situationen** Es gibt Situationen, in denen die im Verschlüsselungsvertrag enthaltenen Informationen unvollständig, mehrdeutig oder falsch sein können. In diesen Fällen ist es wichtig, dass sich der Verschlüsseler und der Schlüsselanbieter angemessen verhalten und einen angemessenen Schutz der Inhalte gewährleisten. Die folgende Tabelle zeigt das empfohlene Verhalten in diesen Situationen: | In dieser Situation | Der Verschlüsseler... should/shall | Der Schlüsselanbieter... should/shall | | --- | --- | --- | | Für einen oder mehrere Titel im Streamset gilt keine Regel (siehe Beispiel 3 unten) | Der Verschlüsseler sollte sich seine Konfiguration (außerhalb der CPIX-Payload) ansehen und sicherstellen, dass die betreffenden Tracks nicht verschlüsselt werden müssen. Wenn dies nicht den Erwartungen entspricht, sollte der Verschlüsseler einen Fehler ausgeben und die Verarbeitung beenden. | *Nicht relevant: Der Schlüsselanbieter hat keine Kenntnis von der Streamset-Struktur.* | | Mehrere Regeln überschneiden sich und schlagen mehrere Inhaltsschlüssel vor, um einen bestimmten Titel zu verschlüsseln | Der Verschlüsseler sollte den zuletzt ContentKeyUsageRule erfolgreich bewerteten Code in der Reihenfolge des Dokuments anwenden. | *Nicht relevant: Der Schlüsselanbieter hat keine Kenntnis von der Streamset-Struktur.* | | Der Verschlüsselungsvertrag ändert sich in einem einzigen SPEKE-Zyklus request/response | Der Verschlüsseler löst eine Ausnahme aus und stoppt die Verarbeitung, da der Schlüsselanbieter nicht für die Definition des Verschlüsselungsvertrags verantwortlich ist. | Um zu verhindern, dass diese Situation von vornherein eintritt, darf der Schlüsselanbieter einen Verschlüsselungsvertrag, der in der CPIX-Payload der SPEKE-Anfrage empfangen wurde, nicht ändern. | | Fehlerhafter Verschlüsselungsvertrag: Ausnahme mit intendedTrackType/Filters Kardinalitätseinschränkungen, nicht unterstützte Filter oder Attribute | Der Verschlüsseler muss eine Ausnahme auslösen, die Verarbeitung beenden und die SPEKE-Anfrage nicht an den Schlüsselanbieter senden, da dies höchstwahrscheinlich zu einem fehlerhaften Schutz der Inhalte führen oder einige Spuren ungeschützt lassen würde. | Der Schlüsselanbieter löst eine Ausnahme aus und gibt die Fehlermeldung „Fehlerhafter Verschlüsselungsvertrag“ zurück. | | Gut formulierter Verschlüsselungsvertrag, der jedoch gegen die DRM-Sicherheitsregeln verstößt: Beispielsweise wird ein einziger Inhaltsschlüssel angefordert, um sowohl Audiotracks als auch UHD-Videotracks zu schützen | Wenn der Verschlüsseler die Einschränkungen der DRM-Sicherheitsstufen kennt, sollte er eine Ausnahme auslösen, die Verarbeitung beenden und die SPEKE-Anfrage nicht an den Schlüsselanbieter senden, da dies höchstwahrscheinlich zum Schutz fehlerhafter Inhalte führen würde. | Der Schlüsselanbieter muss eine Ausnahme auslösen und den Fehler „Angeforderter CPIX-Verschlüsselungsvertrag wird nicht unterstützt“ zurückgeben. | | Fehlender Verschlüsselungsvertrag | Der Verschlüsseler darf keine CPIX-Dokumente versenden, die kein OE-Element enthalten. VideoFilter AudioFilter | Der Schlüsselanbieter löst eine Ausnahme aus und gibt die Fehlermeldung „Fehlender CPIX-Verschlüsselungsvertrag“ zurück. | **Beispiele für Verschlüsselungsverträge** *Beispiel 1: Ein Inhaltsschlüssel für alle Audio- und Videotracks* ``` ``` *Beispiel 2: ein Inhaltsschlüssel für alle Videospuren, ein Inhaltsschlüssel für alle Audiospuren* ``` ``` *Beispiel 3: ein Inhaltsschlüssel für alle Videospuren, unverschlüsselte Audiospuren* ``` ``` *Beispiel 4: mehrere Inhaltsschlüssel für verschiedene Videospuren (SD/HD), ein Inhaltsschlüssel für alle Audiospuren* ``` ``` *Beispiel 5: mehrere Inhaltsschlüssel für verschiedene Videospuren (SD/HD/UHD), ein Inhaltsschlüssel für alle Audiospuren* ``` ``` *Beispiel 6: mehrere Inhaltsschlüssel für verschiedene Videospuren (SD/HD/UHD1/UHD2), ein Inhaltsschlüssel für alle Audiospuren* ``` ``` *Beispiel 7: mehrere Inhaltsschlüssel für verschiedene Videospuren (SD/HD1/HD2/UHD1/UHD2), ein Inhaltsschlüssel für alle Audiospuren* ``` ``` *Beispiel 8: mehrere Inhaltsschlüssel für verschiedene Videospuren (basierend auf mehreren Attributtypen), ein Inhaltsschlüssel für alle Audiospuren* ``` ``` *Beispiel 9: eine Inhaltstaste für alle Videospuren, mehrere Inhaltstasten für Stereo- und Mehrkanal-Audiospuren* ``` ``` *Beispiel 10: ein Inhaltstasten für alle Videospuren, mehrere Inhaltstasten für Stereo und zwei Arten von Mehrkanal-Audiospuren* ``` ``` # SPEKE API v2 — Beispiele für Live-Workflow-Methodenaufrufe *Beispiel für eine Anforderungssyntax* Die folgende URL ist lediglich ein Beispiel und gibt kein bestimmtes Format vor: ``` POST https://speke-compatible-server/speke/v2.0/copyProtection ``` *Anforderungstext* Ein CPIX-Dokument. *Anforderungs-Header* | Name | Typ | Auftreten | Description | | --- | --- | --- | --- | | `AWS Authorization` | Zeichenfolge | 1..1 | Weitere Informationen finden Sie unter [AWS Sigv4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html). | | `X-Amz-Security-Token` | Zeichenfolge | 1..1 | Weitere Informationen finden Sie unter [AWS Sigv4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html). | | `X-Amz-Date` | Zeichenfolge | 1..1 | Weitere Informationen finden Sie unter [AWS Sigv4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html). | | `Content-Type` | Zeichenfolge | 1..1 | application/xml | | `X-Speke-Version` | Zeichenfolge | 1..1 | SPEKE-API-Version, die mit der Anfrage verwendet wurde, formuliert als. MajorVersion MinorVersion, wie '2.0' für SPEKE v2.0 | *Antwort-Header* | Name | Typ | Auftreten | Description | | --- | --- | --- | --- | | `X-Speke-User-Agent` | Zeichenfolge | 1..1 | Zeichenfolge, die den Schlüsselanbieter identifiziert. | | `Content-Type` | Zeichenfolge | 1..1 | application/xml | | `X-Speke-Version` | Zeichenfolge | 1..1 | SPEKE-API-Version, die mit der Anfrage verwendet wurde, formuliert als. MajorVersion MinorVersion, wie '2.0' für SPEKE v2.0 | *Request Response (Antwort anfordern)* | HTTP-CODE | Name der Nutzlast | Auftreten | Description | | --- | --- | --- | --- | | `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. | **Anmerkung** Die Beispiele in diesem Abschnitt zeigen keine Inhaltsschlüssel-Verschlüsselung. Informationen zum Hinzufügen von Inhaltsschlüsselverschlüsselung finden Sie unter [Inhaltsschlüsselverschlüsselung](content-key-encryption-v2.md). *Beispiel für eine Live-Anforderungsnutzlast mit entschlüsselten Schlüsseln* Das folgende Beispiel zeigt eine typische Payload für Live-Anfragen vom Verschlüsseler an den DRM-Schlüsselanbieter mit einem Inhaltsschlüssel für alle Videospuren und einem Inhaltsschlüssel für alle Audiospuren: ``` ``` *Beispiel für eine Live-Antwortnutzlast mit entschlüsselten Schlüsseln* Das folgende Beispiel zeigt eine typische Antwortnutzlast des DRM-Schlüsselanbieters (die zurückgegebenen Werte wurden aus Gründen der Lesbarkeit mit [...] gekürzt): ``` 5dGAgwGuUYu4dHeHtNlxJw== h3toSFIlyAYpfXVQ795m6x== aHR0cHM6L[...]WZm Y29tLmFwc[...]XJ5 trBAnbMcj[...]u44 mn626PjyR[...]2fi Ifa2V5LWl[...]nNB oIARIQeSI[...]Nd2l RoNd2lkZXZ[...]Nib AAAAanBzc[...]A== lTznjvtzL[...]GfJ XgzdzQH7p[...]zeX TdgRnuJsZ[...]wDw mYZbjpWdS[...]D== HicXmbZ2m[...]4== GVzdCIfa2[...]Eta t7WwH24FI[...]YCC FFFFanBzc[...]A== s5RrJ12HL[...]UBB BptGzwis2[...]Iej 3c9SXdVa0[...]MBH HotJCMQyc[...]GpU S6UD43ybN[...]f== VBFUv2or0[...]JeP ``` # SPEKE API v2 — Beispiele für VOD-Workflow-Methodenaufrufe *Beispiel für eine Anforderungssyntax* Die folgende URL ist lediglich ein Beispiel und gibt kein bestimmtes Format vor. ``` POST https://speke-compatible-server/speke/v2.0/copyProtection ``` *Anforderungstext* Ein CPIX-Dokument. *Anforderungs-Header* | Name | Typ | Auftreten | Description | | --- | --- | --- | --- | | `AWS Authorization` | Zeichenfolge | 1..1 | Weitere Informationen finden Sie unter [AWS Sigv4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html). | | `X-Amz-Security-Token` | Zeichenfolge | 1..1 | Weitere Informationen finden Sie unter [AWS Sigv4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html). | | `X-Amz-Date` | Zeichenfolge | 1..1 | Weitere Informationen finden Sie unter [AWS Sigv4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html). | | `Content-Type` | Zeichenfolge | 1..1 | application/xml | | `X-Speke-Version` | Zeichenfolge | 1..1 | SPEKE-API-Version, die mit der Anfrage verwendet wurde, formuliert als. MajorVersion MinorVersion, wie '2.0' für SPEKE v2.0 | *Antwort-Header* | Name | Typ | Auftreten | Description | | --- | --- | --- | --- | | `X-Speke-User-Agent` | Zeichenfolge | 1..1 | Zeichenfolge, die den Schlüsselanbieter identifiziert. | | `Content-Type` | Zeichenfolge | 1..1 | application/xml | | `X-Speke-Version` | Zeichenfolge | 1..1 | SPEKE-API-Version, die mit der Anfrage verwendet wurde, formuliert als. MajorVersion MinorVersion, wie '2.0' für SPEKE v2.0 | *Request Response (Antwort anfordern)* | HTTP-CODE | Name der Nutzlast | Auftreten | Description | | --- | --- | --- | --- | | `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. | **Anmerkung** Die Beispiele in diesem Abschnitt zeigen keine Inhaltsschlüssel-Verschlüsselung. Informationen zum Hinzufügen von Inhaltsschlüsselverschlüsselung finden Sie unter [Inhaltsschlüsselverschlüsselung](content-key-encryption-v2.md). *Beispiel für eine VOD-Anforderungsnutzlast mit entschlüsselten Schlüsseln* Das folgende Beispiel zeigt eine typische Payload für VOD-Anfragen vom Verschlüsseler an den DRM-Schlüsselanbieter mit einem Inhaltsschlüssel für alle Videospuren und einem Inhaltsschlüssel für alle Audiospuren: ``` ``` *Beispiel für eine VOD-Antwortnutzlast mit entschlüsselten Schlüsseln* Das folgende Beispiel zeigt eine typische Antwort-Payload des DRM-Schlüsselanbieters (die zurückgegebenen Werte wurden aus Gründen der Lesbarkeit mit [...] gekürzt): ``` 5dGAgwGuUYu4dHeHtNlxJw== h3toSFIlyAYpfXVQ795m6x== aHR0cHM6L[...]WZm Y29tLmFwc[...]XJ5 trBAnbMcj[...]u44 mn626PjyR[...]2fi Ifa2V5LWl[...]nNB oIARIQeSI[...]Nd2l RoNd2lkZXZ[...]Nib AAAAanBzc[...]A== lTznjvtzL[...]GfJ XgzdzQH7p[...]zeX TdgRnuJsZ[...]wDw mYZbjpWdS[...]D== HicXmbZ2m[...]4== GVzdCIfa2[...]Eta t7WwH24FI[...]YCC FFFFanBzc[...]A== s5RrJ12HL[...]UBB BptGzwis2[...]Iej 3c9SXdVa0[...]MBH HotJCMQyc[...]GpU S6UD43ybN[...]f== VBFUv2or0[...]JeP ``` # SPEKE API v2 — Verschlüsselung von Inhaltsschlüsseln Sie können Ihrer SPEKE-Implementierung optional eine Inhaltsschlüsselverschlüsselung hinzufügen. Die Inhaltsschlüsselverschlüsselung garantiert vollständigen end-to-end Schutz, indem sie zusätzlich zur Verschlüsselung des Inhalts selbst auch die Inhaltsschlüssel für die Übertragung verschlüsselt. Wenn Sie dies nicht für Ihren Schlüsselanbieter implementieren, verlassen Sie sich aus Sicherheitsgründen auf die Verschlüsselung der Transportschicht sowie auf eine starke Authentifizierung. Um die Inhaltsschlüsselverschlüsselung für Verschlüsseler zu verwenden, die in der AWS-Cloud ausgeführt werden, importieren Kunden Zertifikate in den AWS Certificate Manager und verwenden das resultierende Zertifikat dann ARNs für ihre Verschlüsselungsaktivitäten. Der Verschlüsseler verwendet das Zertifikat ARNs und den ACM-Service, um dem DRM-Schlüsselanbieter verschlüsselte Inhaltsschlüssel bereitzustellen. **Einschränkungen** SPEKE unterstützt die Verschlüsselung von Inhaltsschlüsseln gemäß der DASH-IF CPIX-Spezifikation mit den folgenden Einschränkungen: + SPEKE unterstützt keine Überprüfung digitaler Signaturen (XMLDSIG) für Payloads von Anfragen oder Antworten. + SPEKE benötigt 2048 RSA-basierte Zertifikate. Diese Einschränkungen sind auch unter [Anpassungen und Einschränkungen der DASH-IF-Spezifikation](speke-constraints-v2.md) aufgeführt. **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](https://dashif.org/docs/CPIX2.3/Cpix.html) CPIX 2.3-Spezifikation. *Beispiel für das Inhaltsschlüssel-Verschlüsselungselement ` ` in der Anforderungsnutzlast* ``` ... ``` *Beispiel für das Inhaltsschlüssel-Verschlüsselungselement ` ` in der Antwortnutzlast* ``` qnei/5TsfUwDu+8bhsZrLjDRDngvmnUZD2eva7SfXWw= 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 v2 — Überschreiben der Schlüssel-ID 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`: ``` 5dGAgwGuUYu4dHeHtNlxJw== Ifa2V5LWl[...]nNB oIARIQeSI[...]Nd2l RoNd2lkZXZ[...]Nib AAAAanBzc[...]A== ``` # Lizenz für die SPEKE API-Spezifikation ## Creative Commons Namensnennung — ShareAlike 4.0 Internationale öffentliche Lizenz Durch die Ausübung der lizenzierten Rechte (unten definiert) akzeptieren Sie die Bedingungen dieser Creative Commons Attribution- ShareAlike 4.0 International Public License („Öffentliche Lizenz“) und erklären sich damit einverstanden, an diese gebunden zu sein. In dem Umfang, in dem diese öffentliche Lizenz als Vertrag interpretiert werden kann, werden Ihnen die lizenzierten Rechte unter der Voraussetzung gewährt, dass Sie diesen Bestimmungen zustimmen. Der Lizenzgeber gewährt Ihnen diese Rechte aufgrund des Nutzens, der sich für den Lizenzgeber aus der Verfügbarmachung des lizenzierten Materials unter diesen Bestimmungen ergibt. **Abschnitt 1: Definitionen.** 1. Adaptiertes Material bezeichnet Material, das dem Urheberrecht und vergleichbaren Schutzrechten unterliegt, das aus dem lizenzierten Material abgeleitet ist oder darauf basiert und in dem das lizenzierte Material übersetzt, geändert, angeordnet, transformiert oder anderweitig auf eine Weise modifiziert wurde, die nach Urheberrecht oder vergleichbaren Schutzrechten, die vom Lizenzgeber gehalten werden, eine Erlaubnis erforderlich machen. Im Rahmen dieser öffentlichen Lizenz, bei der das lizenzierte Material ein musikalisches Werk, eine Aufführung oder eine Audioaufnahme ist, entsteht immer adaptiertes Material, wenn das lizenzierte Material zeitlich mit bewegten Bildern synchronisiert wird. 1. Die Lizenz von Adapter bedeutet die Lizenz, die Sie gemäß den Bedingungen dieser Public License auf Ihr Urheberrecht und ähnliche Rechte an Ihren Beiträgen zu adaptiertem Material anwenden. 1. BY-SA-kompatible Lizenz bedeutet eine auf creativecommons.org/compatiblelicenses aufgeführte Lizenz, die von Creative Commons als im Wesentlichen dieser Public License gleichwertig genehmigt wurde. 1. Urheberrecht und ähnliche Rechte sind urheberrechtlich ähnliche Rechte, die eng mit dem Urheberrecht and/or verwandt sind, einschließlich, aber nicht beschränkt auf Aufführungs-, Rundfunk-, Tonaufnahme- und Sui-Generis-Datenbankrechte, unabhängig davon, wie die Rechte bezeichnet oder kategorisiert sind. Im Rahmen dieser öffentlichen Lizenz gelten die in Abschnitt 2(b) (1) – (2) nicht als Urheberrechte und vergleichbare Schutzrechte. 1. Wirksame technische Maßnahmen sind Maßnahmen, die ohne entsprechende Befugnisse nicht durch Gesetze umgangen werden dürfen, die Verpflichtungen aus Artikel 11 des am 20. Dezember 1996 verabschiedeten WIPO-Urheberrechtsvertrags und ähnlichen internationalen Übereinkünften erfüllen. and/or 1. Ausnahmen und Beschränkungen bedeuten faire Nutzung, fairen Umgang und and/or jede andere Ausnahme oder Beschränkung des Urheberrechts und ähnlicher Rechte, die für Ihre Nutzung des lizenzierten Materials gelten. 1. Lizenzelemente sind die Lizenzattribute, die im Namen einer Creative Commons Public License aufgeführt sind. Die Lizenzelemente dieser Public License sind Namensnennung und ShareAlike. 1. Lizenziertes Material bezeichnet das künstlerische oder literarische Werk, die Datenbank oder das andere Material, das oder die der Lizenzgeber unter dieser öffentlichen Lizenz bereitstellt. 1. "Lizenzierte Rechte" bezeichnet die Rechte, die Ihnen unter den Bestimmungen dieser öffentlichen Lizenz gewährt werden und die auf alle Urheberrechte und vergleichbare Schutzrechte beschränkt sind, die für Ihre Nutzung des lizenzierten Materials, zu dessen Lizenzierung der Lizenzgeber berechtigt ist, gelten. 1. "Lizenzgeber" bezeichnet natürliche oder juristische Personen, die Rechte unter dieser öffentlichen Lizenz gewähren. 1. "Teilen" bezeichnet das Bereitstellen von Material für die Öffentlichkeit, für das eine Erlaubnis nach Maßgabe der lizenzierten Rechte erforderlich ist, mit beliebigen Mitteln oder Prozessen, also z. B. Reproduktion, öffentliche Darstellung, öffentliche Aufführung, Weitergabe, Verbreitung, Übermittlung oder Import, und das Verfügbarmachen von Material für die Öffentlichkeit unter Einschluss von Methoden, die der Öffentlichkeit den Zugriff auf das Material an selbst gewählten Orten und zu selbst gewählten Zeiten ermöglichen. 1. Unter Sui Generis Database Rights versteht man alle Rechte als das Urheberrecht, die sich aus der Richtlinie 96/9/EG des Europäischen Parlaments und des Rates vom 11. März 1996 über den rechtlichen Schutz von Datenbanken in der geänderten Fassung and/or ergeben, sowie andere im Wesentlichen gleichwertige Rechte überall auf der Welt. 1. "Sie" bezeichnet natürliche oder juristische Personen, die Rechte unter dieser öffentlichen Lizenz ausüben. Die zugehörigen Personal- und Possessivpronomen haben entsprechende Bedeutung. **Abschnitt 2: Geltungsbereich.** 1. Lizenzgewährung. 1. Nach Maßgabe der Bestimmungen dieser öffentlichen Lizenz gewährt der Lizenzgeber Ihnen hiermit eine weltweite, lizenzgebührenfreie, nicht unterlizenzierbare, nicht exklusive und unwiderrufliche Lizenz, die lizenzierten Rechte in Bezug auf das lizenzierte Material auszuüben: 1. das Lizenzmaterial ganz oder teilweise zu reproduzieren und zu teilen; und 1. adaptiertes Material zu produzieren, zu reproduzieren und zu teilen. 1. Ausnahmen und Einschränkungen. Zur Klarstellung: Sofern für Ihre Nutzung Ausnahmen und Einschränkungen gelten, findet diese öffentliche Lizenz keine Anwendung und Sie müssen ihre Bestimmungen nicht erfüllen. 1. Laufzeit. Die Laufzeit dieser öffentlichen Lizenz ist in Abschnitt 6(a) angegeben. 1. Medien und Formate; technische Modifikationen zulässig. Der Lizenzgeber berechtigt Sie, die lizenzierten Rechte in Bezug auf alle Medien und Formate auszuüben, auch wenn diese derzeit noch nicht bekannt oder noch nicht geschaffen wurden, und die zu diesem Zweck erforderlichen technischen Modifikationen vorzunehmen. Der Lizenzgeber and/or erklärt sich damit einverstanden, kein Recht oder keine Befugnis geltend zu machen, Ihnen zu verbieten, technische Änderungen vorzunehmen, die zur Ausübung der lizenzierten Rechte erforderlich sind, einschließlich technischer Änderungen, die zur Umgehung wirksamer technologischer Maßnahmen erforderlich sind. Gemäß diesem Abschnitt 2(a)(4) zulässigerweise vorgenommene Änderungen schaffen im Rahmen dieser öffentlichen Lizenz kein adaptiertes Material. 1. Nachfolgende Empfänger. 1. Angebot des Lizenzgebers – lizenziertes Material. Jeder Empfänger des lizenzierten Materials erhält vom Lizenzgeber automatisch ein Angebot zur Ausübung der lizenzierten Rechte unter den Bestimmungen dieser öffentlichen Lizenz. 1. Zusätzliches Angebot des Lizenzgebers — Angepasstes Material. Jeder Empfänger von adaptiertem Material von Ihnen erhält automatisch ein Angebot des Lizenzgebers, die lizenzierten Rechte an dem adaptierten Material gemäß den Bedingungen der von Ihnen geltenden Adapterlizenz auszuüben. 1. Keine Einschränkungen für nachfolgende Empfänger. Sie dürfen in Bezug auf das lizenzierte Material keine zusätzlichen oder abweichenden Bestimmungen anbieten oder auferlegen oder effektive technologische Maßnahmen anwenden, wenn dies die Ausübung der lizenzierten Rechte eines Empfängers des lizenzierten Materials einschränkt. 1. Keine Billigung. Keine der Aussagen in dieser öffentlichen Lizenz begründet oder darf ausgelegt werden als eine Erlaubnis, zu behaupten oder zu implizieren, dass Sie verbunden sind mit dem, gesponsert sind vom, gebilligt werden vom oder einen offiziellen Status erhalten haben vom Lizenzgeber oder Dritten, denen eine Namensnennung nach Abschnitt 3(a)(1)(A)(i) zusteht, oder dass Ihre Nutzung des lizenzierten Materials im Rahmen einer solchen Verbindung erfolgt. 1. Andere Rechte. 1. Urheberpersönlichkeitsrechte, wie das Recht auf Integrität, sind nicht im Rahmen dieser Public License lizenziert, ebenso wenig wie Öffentlichkeitsrechte, Datenschutz und and/or andere ähnliche Persönlichkeitsrechte. Der Lizenzgeber verzichtet jedoch, soweit möglich, darauf, and/or dass er keine solchen Rechte geltend macht, die dem Lizenzgeber zustehen, soweit dies erforderlich ist, um Ihnen die Ausübung der lizenzierten Rechte zu ermöglichen, aber nicht anderweitig. 1. Patent- und Markenrechte werden unter dieser öffentlichen Lizenz nicht lizenziert. 1. Der Lizenzgeber verzichtet im möglichen Umfang auf jegliches Recht, von Ihnen auf Grundlage einer freiwilligen Lizenz oder einer gesetzlichen oder Zwangslizenz, für die ein Rechtsverzicht möglich ist, für die Ausübung der lizenzierten Rechte Gebühren zu erheben, ob direkt oder über eine Gebührenerhebungsgesellschaft. Für alle anderen Fälle behält sich der Lizenzgeber das Recht zum Erheben solcher Gebühren ausdrücklich vor. **Abschnitt 3: Lizenzbedingungen.** Die Ausübung der lizenzierten Rechte durch Sie setzt ausdrücklich die Einhaltung der folgenden Bedingungen voraus. 1. Nennung. 1. Wenn Sie das lizenzierte Material weitergeben (auch in modifizierter Form), müssen Sie Folgendes angeben: 1. behalten sich Folgendes vor, wenn es vom Lizenzgeber zusammen mit dem Lizenzmaterial geliefert wird: ``` i . identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated); ``` ``` ii . a copyright notice; ``` ``` iii . a notice that refers to this Public License; ``` ``` iv . a notice that refers to the disclaimer of warranties; ``` ``` v . a URI or hyperlink to the Licensed Material to the extent reasonably practicable; ``` 1. geben Sie an, ob Sie das Lizenzmaterial geändert haben, und behalten Sie einen Hinweis auf frühere Änderungen bei; und 1. geben Sie an, dass das lizenzierte Material unter dieser Public License lizenziert ist, und fügen Sie den Text, die URI oder den Hyperlink zu dieser Public License hinzu. 1. Sie können die Bedingungen in Abschnitt 3(a)(1) auf beliebige sinnvolle Weise nach Maßgabe von Medium, Mittel und Kontext erfüllen, mit und in dem Sie das lizenzierte Material weitergeben. Es kann beispielsweise sinnvoll sein, die Bedingungen durch Bereitstellung eines URI oder Hyperlinks auf eine Ressource zu erfüllen, die die erforderlichen Informationen enthält. 1. Wenn der Lizenzgeber dies fordert, müssen Sie die gemäß Abschnitt 3(a)(1)(A) erforderlichen Informationen entfernen, soweit dies praktikabel ist. 1. ShareAlike. Wenn Sie von Ihnen erstelltes adaptiertes Material teilen, gelten zusätzlich zu den Bedingungen in Abschnitt 3 (a) auch die folgenden Bedingungen. 1. Bei der Adapterlizenz, die Sie beantragen, muss es sich um eine Creative Commons-Lizenz mit denselben Lizenzelementen, in dieser Version oder einer späteren Version, oder um eine BY-SA-kompatible Lizenz handeln. 1. Sie müssen den Text oder die URI oder den Hyperlink der Adapterlizenz, die Sie beantragen, angeben. Sie können diese Bedingung auf jede angemessene Weise erfüllen, die auf dem Medium, den Mitteln und dem Kontext basiert, in dem Sie adaptiertes Material teilen. 1. Sie dürfen keine zusätzlichen oder anderen Bedingungen oder Bedingungen anbieten oder ihnen auferlegen oder wirksame technologische Maßnahmen auf adaptiertes Material anwenden, die die Ausübung der Rechte einschränken, die im Rahmen der von Ihnen angewandten Adapterlizenz gewährt wurden. **Abschnitt 4: Datenbankherstellerrechte.** Sofern die lizenzierten Rechte Datenbankherstellerrechte umfassen, die für Ihre Nutzung des lizenzierten Materials gelten, ist Folgendes zu beachten: 1. Zur Klarstellung: Abschnitt 2 (a) (1) gewährt Ihnen das Recht, den gesamten Inhalt der Datenbank oder einen wesentlichen Teil davon zu extrahieren, wiederzuverwenden, zu reproduzieren und weiterzugeben; 1. wenn Sie den gesamten oder einen wesentlichen Teil des Datenbankinhalts in eine Datenbank aufnehmen, an der Sie Sui-Generis-Datenbankrechte haben, dann ist die Datenbank, an der Sie Sui-Generis-Datenbankrechte haben (aber nicht ihre einzelnen Inhalte), adaptiertes Material, auch für die Zwecke von Abschnitt 3 (b); und 1. Sie müssen die Bedingungen in Abschnitt 3(a) erfüllen, wenn Sie den Inhalt der Datenbank ganz oder in substanziellen Teilen weitergeben. Zur Klarstellung: Dieser Abschnitt 4 ergänzt Ihre Pflichten aus dieser öffentlichen Lizenz, sofern die lizenzierten Rechte Urheberrechte und vergleichbare Schutzrechte umfassen, und ersetzt diese Pflichten nicht. **Abschnitt 5: Gewährleistungsausschluss und Haftungsbeschränkung.** 1. Sofern nicht separat anderweitig vom Lizenzgeber zugesichert, bietet der Lizenzgeber das lizenzierte Material im vollständig möglichen Umfang in der vorliegenden und verfügbaren Form an und macht keinerlei Zusicherungen und übernimmt keinerlei Garantien jedweder Art in Bezug auf das lizenzierte Material, ob ausdrücklich, implizit, aus Gesetz oder anderweitig. Dies schließt, ohne darauf beschränkt zu sein, Rechtsmängelgewähr, Handelsüblichkeit, Eignung für einen bestimmten Zweck, Nichtverletzung der Rechte Dritter, Abwesenheit latenter oder anderer Defekte, Genauigkeit sowie das Vorliegen oder Nichtvorliegen von Fehlern, ob bekannt oder erkennbar oder nicht, ein. Da ein vollständiger oder teilweiser Haftungsausschluss nicht überall zulässig ist, betrifft dieser Ausschluss Sie möglicherweise nicht. 1. Im größtmöglichen Umfang wird die Haftung des Lizenzgebers Ihnen gegenüber aus beliebigem Rechtsgrund (einschließlich Fahrlässigkeit, ohne darauf beschränkt zu sein) für unmittelbare, konkrete oder mittelbare Schäden, Nebenkosten, Folgeschäden, Strafzahlungen oder Schadenersatz mit Strafcharakter oder andere Verluste, Kosten, Ausgaben oder Schäden, die sich aus dieser öffentlichen Lizenz oder der Nutzung des lizenzierten Materials ergeben, ausgeschlossen, auch wenn der Lizenzgeber über die Möglichkeit solcher Verluste, Kosten, Ausgaben oder Schäden informiert war. Da eine vollständige oder teilweise Haftungsbeschränkung nicht überall zulässig ist, betrifft diese Beschränkung Sie möglicherweise nicht. 1. Die angegebenen Gewährleistungsausschluss und Haftungsbeschränkungen sind so zu interpretieren, dass das Ergebnis einem vollständigen Ausschluss jeglicher Haftung möglichst nahekommt. **Abschnitt 6: Laufzeit und Beendigung.** 1. Die Geltungsdauer dieser öffentlichen Lizenz entspricht der Geltungsdauer der in dieser Lizenz lizenzierten Urheberrechte und vergleichbaren Schutzrechte. Falls Sie jedoch gegen Bestimmungen dieser öffentlichen Lizenz verstoßen, enden Ihre Rechte aus dieser öffentlichen Lizenz automatisch. 1. Sofern Ihr Recht zur Nutzung des lizenzierten Materials gemäß Abschnitt 6(a) beendet wurde, wird es in folgenden Situationen wiederhergestellt: 1. automatisch ab dem Tag, an dem der Verstoß behoben ist, sofern er innerhalb von 30 Tagen nach Ihrer Entdeckung des Verstoßes behoben wird; oder 1. nach ausdrücklicher Wiedereinstellung durch den Lizenzgeber. 1. Zur Klarstellung: Dieser Abschnitt 6(b) beeinträchtigt in keiner Weise die Rechte des Lizenzgebers, Ihnen gegenüber Rechtsmittel aufgrund Ihrer Verstöße gegen diese öffentliche Lizenz zu ergreifen. 1. Zur Klarstellung: Der Lizenzgeber darf das lizenzierte Material auch unter anderen Bestimmungen anbieten sowie jederzeit die Weitergabe des lizenzierten Materials stoppen. Dadurch wird aber diese öffentliche Lizenzen nicht beendet. 1. Die Abschnitte 1, 5, 6, 7 und 8 gelten nach Beendigung dieser öffentlichen Lizenz fort. **Abschnitt 7: Andere Bestimmungen.** 1. Der Lizenzgeber wird durch zusätzliche oder abweichende Bestimmungen in Mitteilungen von Ihnen nicht gebunden, sofern dies nicht ausdrücklich vereinbart wird. 1. Alle Arrangements, Absprachen oder Verträge in Bezug auf das lizenzierte Material, die nicht in diesem Dokument enthalten sind, gelten separat und unabhängig von den Bestimmungen dieser öffentlichen Lizenz. **Abschnitt 8: Interpretation.** 1. Zur Klarstellung: Diese öffentliche Lizenz stellt keine Einschränkung, Limitierung oder Beschränkung einer Nutzung des lizenzierten Materials dar, unterwirft diese Nutzung keinen Bedingungen und darf nicht interpretiert werden, als wäre dies ihr Zweck, sofern die betreffende Nutzung rechtmäßig ohne Erlaubnis durch diese öffentliche Lizenz möglich wäre. 1. In dem Umfang, in dem eine Bestimmung dieser öffentlichen Lizenz als undurchsetzbar gefunden wird, wird sie automatisch in geringstmöglichem Umfang umgeformt, um ihre Durchsetzbarkeit zu ermöglichen. Kann die Bestimmung nicht umgeformt werden, ist sie von dieser öffentlichen Lizenz abzutrennen, ohne dass dies die Durchsetzbarkeit der übrigen Bestimmungen beeinträchtigen würde. 1. Ein Rechtsverzicht auf eine der Bestimmungen dieser öffentlichen Lizenz sowie eine Zustimmung zu einem Verstoß gegen die Bestimmungen dieser öffentlichen Lizenz ist nur durch ausdrückliche Vereinbarung seitens des Lizenzgebers möglich. 1. Keine der Aussagen in dieser öffentlichen Lizenz begründet oder darf interpretiert werden als eine Beschränkung der oder ein Verzicht auf Rechte und Privilegien, die für den Lizenzgeber oder Sie gelten, einschließlich der aus rechtlichen Verfahren von Jurisdiktionen oder Behörden erwachsenden Rechte und Privilegien.