Creazione di pacchetti e recapito di contenuti

La funzionalità di base di PlayReady consiste nel proteggere il contenuto da usi non autorizzati. A tale scopo, il contenuto deve prima essere crittografato e un'intestazione PlayReady associata deve essere inserita nel contenuto. Il sistema che esegue questa operazione è il packager, noto anche come encryptor, che a volte è integrato con il codificatore.

Questo argomento descrive diversi modi per crittografare e distribuire il contenuto usando PlayReady.

Creazione di pacchetti di contenuto PlayReady - Crittografia e inserimento dell'intestazione DRM

Il processo di crittografia del contenuto non crittografato consiste nel definire una o più chiavi di crittografia, usando queste chiavi per crittografare i byte che costituiscono il contenuto stesso e inserendo un'intestazione DRM nel contenuto (nei file del contenuto o nel manifesto se il contenuto ne ha uno).

Tutto il contenuto crittografato protetto da PlayReady deve avere un'intestazione PlayReady inserita nel file crittografato. L'intestazione PlayReady viene utilizzata da un client PlayReady per individuare o acquisire una licenza per quel determinato contenuto. Un'intestazione PlayReady è costituita da XML codificato in UTF-16. Include gli identificatori di chiave (KID) usati per crittografare il contenuto, un URL predefinito che il client userà per acquisire una licenza da se non vengono forniti altri attributi e attributi personalizzati.  

Qualsiasi packager che crea pacchetti di contenuto non crittografato deve implementare un generatore di intestazioni PlayReady per compilare l'intestazione e incorporarlo nel contenuto crittografato. L'intestazione PlayReady deve essere implementata in base alla specifica dell'intestazione PlayReady. Esistono diversi modi per creare un generatore di intestazioni PlayReady nel packager:

• Sviluppalo tu stesso in base alla specifica dell'intestazione PlayReady. 
• Usare l'API PlayReady Server SDK che genera un'intestazione PlayReady. 
• Usa l'API di Windows 10 che genera un'intestazione PlayReady. 

Il contenuto crittografato può contenere più intestazioni DRM, incluse le intestazioni PlayReady insieme alle intestazioni DRM di terze parti. Per altre informazioni sul funzionamento, vedere Uso degli strumenti di crittografia.

Tipo di contenuto

PlayReady può essere usato per proteggere il contenuto audio e video. I tipi più comuni di codifica usati con PlayReady sono gli standard MPEG-4 AVC (H.264), HEVC (High Efficiency Video Coding) H.265 e AV1 standard. PlayReady non è limitato a questi standard e può essere usato con qualsiasi formato audio e video supportato nel dispositivo client.

PlayReady versione 1 e 2 consente di creare un pacchetto protetto contenente contenuto non limitato ai payload audio o video. Questi pacchetti, detti buste, possono contenere file come una raccolta di file di dati ed eseguibili (ad esempio, un'applicazione distribuita da un archivio applicazioni), immagini (ad esempio, sfondo dello schermo) o ebook. Questo contenuto viene inserito in un pacchetto incapsulando i file in un file envelope, che può essere decrittografato in modo simile al contenuto audio/video.

Questi tipi di contenuto non audio/video non sono più supportati in PlayReady 3.0 e versioni successive. 

Strumenti di crittografia

Microsoft non include un packager come parte dei materiali di PlayReady. PlayReady fornisce invece specifiche basate su standard di crittografia comuni per l'uso da parte dei codificatori. Pertanto, il formato di crittografia non è specifico di PlayReady, ma è una funzione del formato di file. Il formato di crittografia più diffuso oggi è il formato Standard ISO di crittografia comune, ISO/IEC 23001-7.

In pratica, è possibile creare un packager personalizzato o usare qualsiasi tipo di encryptor open source, ad esempio ffmpeg. Inoltre, è possibile collaborare con una società di codificatori professionisti se si vuole crittografare il contenuto con PlayReady (ad esempio Armonica, Elemental, Ericsson, Wowza, Allegro).

Uso degli strumenti di crittografia

PlayReady supporta lo standard di crittografia comune ISO IEC. Questo processo è identico a quello descritto in Crittografia di base e processo di licenza, ad eccezione delle intestazioni che verranno incluse per altri DRM, ognuno dei quali come payload della casella Intestazione specifica del sistema di protezione ('pssh'), identificato dal SystemID di TALE DRM. Tutte queste intestazioni avranno la propria sintassi che designa i KID o le informazioni necessarie per accedere alle chiavi di contenuto. Le chiavi di contenuto per questo asset saranno le stesse per tutti i DRM.

Uso delle chiavi di crittografia

Esistono molti modi diversi per crittografare gli asset. Quello più semplice per quello più sofisticato dipende dalla complessità che si vuole progettare nel sistema e dalle esigenze del servizio.

Si prenda ad esempio un asset di streaming adattivo, come illustrato nella figura seguente. Ha quattro diverse qualità video, una traccia audio e una traccia di sottotitolo. È codificato in file MP4 segmentati, con segmenti di 2,0 secondi ciascuno. Si tratta di un asset che viene servito in più formati a seconda di ciò che il client preferisce riprodurre. Smooth Streaming, HLS e DASH sono le varianti più comuni. Durante la riproduzione, il client (lettore video) scarica successivamente i segmenti dell'asset in rete, selezionando per ogni tempo di riproduzione il segmento video dalla traccia video adeguata, al fine di mantenere la qualità di riproduzione il più alta possibile, in base ai vincoli della larghezza di banda di rete, alla velocità di riproduzione e ad altre risorse limitate come le funzionalità del lettore. Questa logica è nota come riproduzione in streaming adattivo, governata da alcune regole euristiche implementate nel lettore. 

Crittografia dell'asset con una sola chiave

Il modo più semplice per crittografare questi asset consiste nell'usare una singola chiave simmetrica per crittografare tutto (in genere i sottotitoli non sono crittografati, non è contro alcuna regola, ma in genere vengono mantenuti in chiaro). L'uso di una chiave di contenuto rende la vita facile per il server licenze perché il server licenze deve distribuire una sola chiave {KID, CK}. Questa chiave viene in genere acquisita dal client prima che si verifichi la riproduzione.

Annotazioni

I client PlayReady possono acquisire licenze in modo proattivo o reattivo. Per una descrizione di queste due modalità, vedere la pagina Acquisizione licenze .

Crittografia dell'asset con due chiavi, dedicandone una alla massima qualità

Negli ultimi anni sono stati apportati alcuni miglioramenti per l'uso di più chiavi per asset, principalmente basate sul requisito di consentire solo a determinati client con la massima affidabilità di utilizzare il contenuto di alta qualità. Con l'arrivo di contenuti Ultra HD (4K) e con l'aggiunta di una gamma dinamica elevata (HDR) per contenuti di colore più elevati, c'era bisogno di studi e servizi per consentire la massima qualità solo su determinati client, che in genere hanno DRM hardware integrato. In questo scenario, l'asset viene crittografato usando una chiave simmetrica {kid1, ck1} per tutte le tracce, ad eccezione della traccia 4K crittografata usando una chiave simmetrica diversa {kid2, ck2}. Cioè:

• Un client autorizzato a riprodurre solo in Full HD (non la traccia 4K) verrà recapitato una licenza PlayReady che include solo {kid1, ck1}. 
• Un client autorizzato a riprodurre fino a 4K verrà fornito una licenza PlayReady che include {kid1, ck1} e {kid2, ck2}.

Usando questa complessità aggiuntiva, il servizio può garantire che alcuni client non saranno in grado di decrittografare la traccia 4K e che la traccia 4K può essere riservata solo ai client che il servizio considera più attendibile. 

Crittografia dell'asset con una chiave per traccia

Il servizio può avere una mappa più complessa dei diritti da applicare. Alcuni client, a seconda delle dimensioni dello schermo, della loro robustezza, dei relativi output e della loro posizione, possono essere autorizzati ad accedere solo ad alcune tracce video, alcune qualità video e alcune tracce audio. Per garantire che il servizio abbia la massima flessibilità nell'applicazione di un set arbitrario di restrizioni in futuro, può crittografare un asset con una chiave simmetrica specifica per ogni traccia. Per esempio:

• Un client autorizzato a riprodurre solo in 720p verrà fornita una licenza PlayReady, tra cui {kid1, ck1}, {kid2, ck2} e {kidA, ckA}. 
• Un client autorizzato a giocare fino a 4K verrà consegnata una licenza PlayReady, tra cui {kid1, ck1}, {kid2, ck2}, {kid3, ck3}, {kid4, ck4}e {kidA, ckA}. 
• A un client che utilizza offline la versione 4K dell'asset (scaricato in precedenza) verrà recapitata una licenza PlayReady, tra cui {kid4, ck4} e {kidA, ckA}. 

Modifica periodica delle chiavi di crittografia (asset multi-periodo) - Rotazione delle licenze

In alcuni scenari, il servizio vuole modificare occasionalmente le chiavi di crittografia, in genere ai limiti del programma. Ad esempio, un flusso lineare live ha più periodi con contenuti gratuiti a cui si vuole che tutti abbiano accesso, seguito da alcuni contenuti limitati ai sottoscrittori. La modifica delle chiavi di crittografia ai confini del programma consente al servizio di distribuire le chiavi in chiaro {KIDi1, CKi1} a tutti gli utenti senza restrizioni e di distribuire le chiavi di contenuto {kidi2, cki2} solo agli abbonati che hanno effettuato correttamente l'accesso al servizio.

Si noti che questa rotazione delle licenze non è molto scalabile: ogni volta che le chiavi di crittografia cambiano, tutti i client richiedono le nuove chiavi di crittografia usando la propria richiesta di licenza. Ciò può comportare un picco elevato di richieste di licenza nei sistemi con un numero elevato di client. 

Modifica frequente delle chiavi di crittografia: rotazione delle chiavi scalabile

Esiste un meccanismo avanzato in PlayReady denominato rotazione delle chiavi scalabile (anziché rotazione delle licenze). Questo metodo archivia un archivio licenze incorporato (ELS) nel flusso del contenuto effettivo. In questo meccanismo, la chiave usata per crittografare il segmento A2 stesso è denominata chiave foglia {kidA2, ckA2}, e viene distribuita nell'ELS del segmento A2, essendo se stessa crittografata con una chiave separata che è la stessa per tutti i segmenti di traccia A, denominata chiave radice {kidRA, ckRA}. Se si ha familiarità con MPEG-2 TS e la crittografia control Word, si tratta di un meccanismo simile ad eccezione della crittografia molto più forte e anche più flessibile.

Si supponga che questo asset sia live linear TV. Quando il client tenta di riprodurre, trova kidRA nell'intestazione PlayReady del manifesto del flusso e richiede una licenza per kidRA. Il server licenze fornisce una licenza principale per la chiave principale {kidRA, ckRA}. Il client analizza quindi il segmento A1 e individua l'ELS nell'intestazione del segmento. Analizzando questo ELS, rileva la licenza fogliare {kidA1, ckA1} in questo ELS. Usando la chiave radice {kidRA, ckRA} e la licenza foglia {kidA1, ckA1}, può ottenere il valore di ckA1 e decrittografare ed eseguire il rendering del segmento A1. 

La funzionalità di rotazione delle chiavi scalabile PlayReady è estremamente scalabile perché non richiede ai client di contattare il server licenze ogni volta che le chiavi di crittografia vengono modificate. Mantiene il volume delle richieste di licenza il più basso possibile, poiché un client necessita di una sola licenza principale dal server licenze per flusso o traccia. Consente alle chiavi di crittografia di ruotare con la frequenza di ciascun segmento, in genere ogni due secondi, se necessario. 

Vedere anche

Chiave e ID chiave (KIDs)