Inhoudsverpakking en -levering

De basismogelijkheid van PlayReady is om inhoud te beschermen tegen onbevoegd gebruik. Hiervoor moet uw inhoud eerst worden versleuteld en wordt er een bijbehorende PlayReady-header ingevoegd in de inhoud. Het systeem dat deze bewerking doet, is de packager, ook wel bekend als de encryptor, die soms is geïntegreerd met de encoder.

In dit onderwerp worden verschillende manieren beschreven om uw inhoud te versleutelen en te leveren met behulp van PlayReady.

PlayReady-inhoud verpakken : de DRM-header versleutelen en invoegen

Het versleutelen van duidelijke inhoud bestaat uit het definiëren van een of meer versleutelingssleutels, waarbij deze sleutels worden gebruikt om de bytes te versleutelen die de inhoud zelf vormen en een DRM-header in de inhoud in te voegen (in de bestanden van de inhoud of in het manifest als de inhoud er een heeft).

Alle versleutelde inhoud die door PlayReady wordt beveiligd, moet een PlayReady-header hebben ingevoegd in het versleutelde bestand. Deze PlayReady-header wordt gebruikt door een PlayReady-client om een licentie voor dat specifieke deel van de inhoud te zoeken of te verkrijgen. Een PlayReady-header bestaat uit XML die is gecodeerd in UTF-16. Het bevat de sleutel-id's (KID's) die worden gebruikt voor het versleutelen van de inhoud, een standaard-URL die de client gebruikt om een licentie te verkrijgen als er geen andere wordt opgegeven en eventuele aangepaste kenmerken.  

Elke packager die inhoud verpakt, moet een PlayReady Header-generator implementeren om de header te bouwen en in te sluiten in de versleutelde inhoud. De PlayReady-header moet worden geïmplementeerd volgens de PlayReady-headerspecificatie. Er zijn meerdere manieren om een PlayReady Header-generator te maken in uw packager:

• Ontwikkel deze zelf op basis van de playReady-headerspecificatie. 
• Gebruik de PlayReady Server SDK-API waarmee een PlayReady-header wordt gegenereerd. 
• Gebruik de Windows 10-API waarmee een PlayReady-header wordt gegenereerd. 

Uw versleutelde inhoud kan meerdere DRM-headers bevatten, waaronder PlayReady-headers, samen met DRM-headers van derden. Zie Versleutelingshulpprogramma's gebruiken voor meer informatie over hoe dit werkt.

Inhoudstype

PlayReady kan worden gebruikt om audio- en video-inhoud te beveiligen. De meest voorkomende typen codering die met PlayReady worden gebruikt, zijn MPEG-4 AVC (H.264), H.265-standaarden (High Efficiency Video Coding) H.265 en de AV1-standaard. PlayReady is niet beperkt tot deze standaarden en kan worden gebruikt met elke audio- en video-indeling die wordt ondersteund op het clientapparaat.

Met PlayReady versie 1 en 2 kunt u een beveiligd pakket maken met inhoud die niet beperkt is tot nettoladingen voor audio of video. Deze pakketten, ook wel enveloppen genoemd, kunnen bestanden bevatten, zoals een verzameling gegevensbestanden en uitvoerbare bestanden (bijvoorbeeld een toepassing die wordt gedistribueerd door een toepassingsarchief), afbeeldingen (bijvoorbeeld schermachtergrond) of ebooks. Deze inhoud wordt verpakt door de bestanden in te kapselen in een envelopbestand, dat op een manier kan worden ontsleuteld op een manier die vergelijkbaar is met audio-/video-inhoud.

Deze niet-audio-/video-inhoudstypen worden niet meer ondersteund in PlayReady 3.0 en hoger. 

Hulpprogramma's voor versleuteling

Microsoft levert geen packager als onderdeel van de PlayReady-leveringen. PlayReady biedt in plaats daarvan specificaties op basis van algemene versleutelingsstandaarden voor gebruik door coderingsprogramma's. Daarom is de versleutelingsindeling niet specifiek voor PlayReady, maar is het een functie van de bestandsindeling. De meest gebruikte versleutelingsindeling vandaag de dag is de Common Encryption ISO Standard-indeling, ISO/IEC 23001-7.

In principe kunt u uw eigen packager maken of u kunt werken met elk type opensource-versleuteling (zoals ffmpeg). Daarnaast kunt u met een professioneel encoderbedrijf samenwerken als u inhoud wilt versleutelen met PlayReady (zoals Harmonic, Elemental, Ericsson, Wowza, Allegro).

Versleutelingshulpprogramma's gebruiken

PlayReady ondersteunt de algemene ISO IEC-versleutelingsstandaard. Dit proces is hetzelfde als beschreven in het basisversleutelings- en licentieproces, behalve dat headers zullen worden opgenomen voor andere DRM's, elk als payload van de Beveiligingssysteem-specifieke header ('pssh') box, geïdentificeerd door de SystemID van die DRM. Al deze headers hebben hun eigen syntaxis die de KID's aanwijst of de informatie die nodig is om uiteindelijk toegang te krijgen tot de inhoudssleutels. En de inhoudssleutels voor deze asset zijn hetzelfde voor alle DRM's.

Versleutelingssleutels gebruiken

Er zijn veel verschillende manieren om uw assets te versleutelen. De eenvoudigste voor de meest geavanceerde is afhankelijk van de complexiteit die u in het systeem wilt ontwerpen en wat de behoeften van de service zijn.

Laten we bijvoorbeeld een adaptieve streamingasset nemen, zoals wordt weergegeven in de onderstaande afbeelding. Het heeft vier verschillende videokwaliteiten, één audiospoor en één ondertitelingsspoor. Het wordt gecodeerd in gesegmenteerde MP4-bestanden, met segmenten van 2,0 seconden elk. Het is één asset die in meerdere indelingen wordt geleverd, afhankelijk van wat de client liever wil afspelen. Smooth Streaming, HLS en DASH zijn de meest voorkomende varianten. Tijdens het afspelen downloadt de client (de videospeler) achtereenvolgens de segmenten van de asset via het netwerk en selecteert deze voor elke afspeeltijd van het videosegment van het geschikte videospoor, om de afspeelkwaliteit zo hoog mogelijk te houden, gezien de beperkingen van de netwerkbandbreedte, de afspeelsnelheid en andere beperkte bronnen, zoals de spelermogelijkheden. Deze logica wordt adaptieve streamingweergave genoemd, die wordt bepaald door een aantal heuristiekregels die in de speler zijn geïmplementeerd. 

De asset versleutelen met slechts één sleutel

De eenvoudigste manier om deze assets te versleutelen, is door één inhoudssleutel te gebruiken om alles te versleutelen (meestal worden ondertitels niet versleuteld; het is niet tegen een regel, maar ze worden meestal duidelijk bewaard). Als u één inhoudssleutel gebruikt, is het eenvoudig voor de licentieserver omdat de licentieserver één sleutel {KID, CK} moet leveren. Deze sleutel wordt doorgaans verkregen door de client voordat het afspelen plaatsvond.

Het versleutelen van de asset met twee sleutels, waarbij er een wordt aangeduid met de hoogste kwaliteit

De afgelopen jaren zijn er enkele verbeteringen aangebracht om meerdere sleutels per asset te gebruiken, voornamelijk gebaseerd op de vereiste dat alleen bepaalde clients met de hoogste robuustheid de inhoud van de hoogste kwaliteit kunnen gebruiken. Met de komst van Ultra HD -inhoud (4K) en met toevoeging van hoog dynamisch bereik (HDR) voor hogere kleurinhoud, was er behoefte aan studio's en services om de hoogste kwaliteit alleen toe te staan op bepaalde clients, die doorgaans hardware DRM hebben ingebouwd. In dit scenario wordt de asset versleuteld met behulp van één inhoudssleutel {kid1, ck1} voor alle sporen, met uitzondering van het 4K-spoor dat is versleuteld met behulp van een andere inhoudssleutel {kid2, ck2}. Dat wil zeggen:

• Een client die alleen Full HD mag afspelen (niet de 4K-track) krijgt een PlayReady-licentie met alleen {kid1, ck1}. 
• Een client die maximaal 4K mag spelen, ontvangt een PlayReady-licentie, waaronder {kid1, ck1} en {kid2, ck2}.

Door deze extra complexiteit te gebruiken, kan de service ervoor zorgen dat sommige clients de 4K-track niet kunnen ontsleutelen en dat 4K-track kan worden gereserveerd voor alleen de clients die de meeste vertrouwensrelaties hebben. 

De asset versleutelen met één sleutel per track

De service kan een complexere kaart met rechten hebben om af te dwingen. Sommige clients, afhankelijk van hun schermgrootte, hun robuustheid, hun uitvoer en hun locatie, hebben mogelijk alleen toegang tot sommige videosporen, sommige videokwaliteiten en sommige audiosporen. Om ervoor te zorgen dat de service in de toekomst volledige flexibiliteit heeft bij het afdwingen van een willekeurige set beperkingen, kan het een asset versleutelen met een inhoudssleutel die specifiek is voor elk spoor. Bijvoorbeeld:

• Een client die slechts 720p mag spelen, ontvangt een PlayReady-licentie, waaronder {kid1, ck1}, {kid2, ck2} en {kidA, ckA}. 
• Een client die maximaal 4K mag spelen, ontvangt een PlayReady-licentie, waaronder {kid1, ck1}, {kid2, ck2}, {kid3, ck3}, {kid4, ck4} en {kidA, ckA}. 
• Een client die de offline 4K-versie van de asset afspeelt (eerder gedownload), ontvangt een PlayReady-licentie, inclusief {kid4, ck4} en {kidA, ckA}. 

De versleutelingssleutels periodiek wijzigen (asset met meerdere perioden):licentierotatie

In sommige scenario's wil de service de versleutelingssleutels af en toe wijzigen, meestal op programmagrenzen. Een live lineaire stream heeft bijvoorbeeld meerdere perioden met gratis inhoud waartoe iedereen toegang moet hebben, gevolgd door bepaalde inhoud die is beperkt tot abonnees. Door de versleutelingssleutels aan programmagrenzen te wijzigen, kan de service de gratis luchtsleutels {KIDi1, CKi1} zonder beperkingen aan alle gebruikers leveren en de inhoudssleutels {kidi2, cki2} alleen leveren aan de abonnees die zich hebben aangemeld bij de service.

Houd er rekening mee dat deze licentierotatie niet erg schaalbaar is: telkens wanneer de versleutelingssleutels veranderen, vragen alle clients de nieuwe versleutelingssleutels aan met behulp van hun eigen licentieaanvraag. Dit kan leiden tot een hoge piek van licentieaanvragen in systemen met een groot aantal clients. 

De versleutelingssleutels regelmatig wijzigen: schaalbare sleutelrotatie

Er is een geavanceerd mechanisme in PlayReady dat schaalbare sleutelrotatie wordt genoemd (in plaats van licentierotatie). Met deze methode wordt een ELS (Embedded License Store) opgeslagen in de stroom van de werkelijke inhoud. In dit mechanisme wordt de sleutel die wordt gebruikt voor het versleutelen van het A2-segment zelf de leaf-sleutel {kidA2, ckA2} genoemd en wordt geleverd in de ELS van het segment A2, die zelf wordt versleuteld met een afzonderlijke sleutel die hetzelfde is voor alle segmenten van track A, de hoofdsleutel {kidRA, ckRA}. Als u bekend bent met MPEG-2 TS en de Control Word-versleuteling, is dit een vergelijkbaar mechanisme, behalve dat de versleuteling veel sterker is en ook flexibeler is.

Stel dat dit activum live lineair tv is. Wanneer de client probeert af te spelen, wordt kidRA gevonden in de PlayReady-header van het streammanifest en wordt een licentie voor kidRA aangevraagd. De licentieserver retourneert een basislicentie voor de hoofdsleutel {kidRA, ckRA}. Vervolgens parseert de client segment A1 en detecteert de ELS in de header van het segment. Als u deze ELS parseert, vindt u de leaf-licentie {kidA1, ckA1} in deze ELS. Met behulp van de hoofdsleutel {kidRA, ckRA} en de leaf-licentie {kidA1, ckA1}, kan deze de waarde van ckA1 ophalen en het segment A1 ontsleutelen en weergeven. 

De functie playReady scalable sleutelrotatie is uiterst schaalbaar omdat clients niet telkens contact hoeven te maken met de licentieserver wanneer de versleutelingssleutels worden gewijzigd. Het houdt het volume van licentieaanvragen op het laagst mogelijke niveau, omdat een client slechts één hoofdlicentie van de licentieserver per stream of track nodig heeft. Hiermee kunnen versleutelingssleutels zo vaak als per segment roteren, meestal om de twee seconden, indien nodig. 

Zie ook

Sleutel- en sleutel-ID's (KIDs)