Sistema end-to-end semplice
In genere, Microsoft PlayReady protegge il contenuto fornendo licenze per i file multimediali. Non è necessario nascondere i file, renderli inaccessibili o applicare una protezione speciale quando i file vengono trasmessi dal sistema al sistema. In altre parole, non sono necessari requisiti del sistema operativo o meccanismi di trasporto file con sicurezza elevata. Tuttavia, la copia di un file e la consegna a un amico non consentirà a tale amico di usare il file se è protetto da PlayReady. Per usare un file multimediale, gli utenti necessitano di una licenza. Questa licenza è il mezzo principale per esercitare il controllo sul contenuto (il file multimediale). Una licenza viene concessa a un singolo client (ad esempio un lettore multimediale) o a un dominio. La licenza non funzionerà su altri client o altri domini.
Ogni licenza contiene diritti e restrizioni, definendo esattamente il modo in cui il contenuto può essere usato e in quali condizioni. Ad esempio, una licenza di file musicali può abilitare un "diritto di riproduzione", ma limitare il livello di sicurezza dell'applicazione in cui è possibile riprodurre il contenuto. La licenza potrebbe essere valida per il periodo compreso tra il 1° ottobre 2017 e il 1° novembre 2017. Potrebbero essere presenti più licenze per un singolo file. Un utente sarà in grado di accedere e usare il contenuto, purché una delle licenze conceda i diritti appropriati e le restrizioni non impediscono l'accesso.
Panoramica di un servizio video end-to-end
La figura seguente contiene un'analisi generale di un servizio video end-to-end, incluso il back-end del servizio a sinistra e i client a destra.
Sul lato sinistro dell'illustrazione è possibile vedere che il servizio dispone di alcuni server per trasmettere il video (rete di distribuzione del contenuto). Esistono anche alcuni server che consentono agli utenti di esplorare il contenuto e scegliere il contenuto che desidera riprodurre (interfaccia utente). Inoltre, esistono alcuni server che consentono agli utenti di accedere e di essere autenticati, nonché pagare per il contenuto (autenticazione, pagamento). E c'è anche un server licenze PlayReady.
Sul lato destro dell'illustrazione sono i client. I client potrebbero essere Windows applicazioni, applicazioni smartphone o dispositivi specifici come set top box, ricevitori di rete e così via. Alcuni di questi client possono essere dotati di un client integrato PlayReady nei loro giocatori, ad esempio, l'OEM potrebbe avere integrato PlayReady nel sistema operativo o nell'hardware. Altri utenti possono essere dotati di un client integrato nell'applicazione pubblicata nell'App Store. Ci sono molte opzioni diverse per i giocatori per integrare PlayReady sul lato client.
Questo argomento descrive le operazioni eseguite da PlayReady per un servizio, come illustrato nella figura seguente.
Ciò che PlayReady offre è un modo per un client di richiedere licenze da un server, che quindi distribuisce le chiavi che proteggono il contenuto in un modulo protetto tramite una rete aperta. La seconda cosa che PlayReady fa è fornire diritti e restrizioni corrette al client. Con PlayReady, il servizio ha la possibilità di fornire una chiave per la riproduzione del contenuto, ma, ad esempio, consente al client di usare tale chiave per due giorni in uno scenario di noleggio. PlayReady offre quindi un modo per dichiarare i diritti e le restrizioni corrette con la chiave.
PlayReady offre anche un modo per archiviare in modo più sicuro la chiave simmetrica sul lato client, in modo che il client sia in grado di usare tale chiave client per decrittografare il contenuto per il rendering, ma non consentire di salvare il contenuto in chiaro e condividerlo con altri utenti.
Per garantire che i client PlayReady si comportino in modo corretto, PlayReady richiede implementazioni hardware e software per seguire le regole di conformità e affidabilità. Queste regole regolano il comportamento di un client quando decrittografa o elabora il contenuto PlayReady. Richiedono inoltre che i client elaborino correttamente le restrizioni rilevate in una licenza. Pertanto, se un client riceve istruzioni per usare la chiave simmetrica per non più di 48 ore, il client deve seguire queste istruzioni. Queste regole vengono fornite da Microsoft nelle regole di conformità e affidabilità e spetta allo sviluppatore client applicare tali regole nei propri client.
Processo di crittografia e licenza di base
I passaggi seguenti illustrano il processo di crittografia e licenza end-to-end per il contenuto e il modo in cui PlayReady è coinvolto nel processo.
La figura seguente contiene un asset, ovvero un file audio/video, che non è stato crittografato. Il metodo usato per crittografare il contenuto dipende interamente dal provider di contenuti e non viene fornito come parte di PlayReady.
Per crittografare questo file, il servizio deve usare un generatore di chiavi nel relativo encryptor di contenuto che genera una nuova chiave simmetrica che verrà usata per crittografare il contenuto. Questa chiave simmetrica verrà successivamente distribuita dal server licenze PlayReady al client per consentire la decrittografia del contenuto e il rendering per l'utente. Insieme alla chiave simmetrica, ovvero un valore privato, i servizi di crittografia associano anche un identificatore di chiave (KeyID), ovvero un GUID, alla chiave simmetrica. KeyID è un valore pubblico.
La chiave e l'ID chiave sono progettati in fase di crittografia e vengono archiviati in un sistema di gestione delle chiavi, che in genere è un tipo di database. PlayReady non fornisce il sistema di gestione delle chiavi, quindi spetta al servizio o al partner che compila il servizio con l'emittente per fornire il sistema di gestione delle chiavi.
Oltre a archiviare la chiave e l'ID chiave nel sistema di gestione delle chiavi, sarà necessario adattare l'ID chiave a un packager, che genera quindi un'intestazione. Questa intestazione viene formattata dal servizio o dal partner in base alla specifica dell'intestazione PlayReady e quindi inserita nell'intestazione del file di contenuto non crittografata.
A questo punto, l'audio e il video verranno crittografati usando l'ID chiave e si avrà un file di contenuto crittografato pronto per essere recapitato a un client.
A questo punto, il client può iniziare a usare il contenuto. La prima cosa che il client probabilmente eseguirà consiste nell'autenticare l'utente nel servizio, in genere specificando un nome di accesso e una password, ma qualsiasi altro meccanismo per l'autenticazione dell'utente e del dispositivo è corretto. In genere, un token di sessione viene restituito al client dopo la verifica dell'utente. Si noti che qualsiasi meccanismo viene usato per l'autenticazione utente, spetta interamente al servizio il modo in cui l'utente viene autenticato; PlayReady non fornisce questa tecnologia.
Successivamente, il contenuto viene recapitato al client( ad esempio, il client ha iniziato a scaricare parte del flusso di dati che costituisce il contenuto). Il client inizia quindi ad analizzare questo contenuto e rileva che è crittografato e usa una chiave sconosciuta, ma contiene un KEYID.
A questo punto, il client invierà una richiesta di acquisizione della licenza al server licenze.
Il server licenze si interfaccia quindi con il servizio di autenticazione per verificare l'utente. In genere, la prima operazione eseguita dal server licenze è verificare che il client o l'utente disponga del diritto per tale licenza specifica. Anche in questo caso, PlayReady non fornisce tale layout (autenticazione), viene fornito solo il server licenze. Il servizio di autenticazione risponderà in genere con sì o no o forse sì con restrizioni (ad esempio, questo utente ha il diritto per questo particolare filmato, ma solo a una qualità inferiore del video perché l'utente non ha il livello di sottoscrizione di qualità più alto, in base all'importo pagato dall'utente al mese).
Il server licenze richiede quindi il valore della chiave, in base all'ID chiave, dal sistema di gestione delle chiavi che archivia le chiavi e il sistema di gestione delle chiavi risponde a tale richiesta. Solo per ripetere, PlayReady non fornisce i componenti del sistema di gestione delle chiavi, quindi ci sarà una richiesta proveniente dal server licenze PlayReady a qualsiasi componente creato dal servizio per archiviare le chiavi.
La chiave viene ricevuta dal server licenze e il server licenze può fornire la licenza. La risposta della licenza PlayReady protetta include il valore della chiave e un elenco di diritti e restrizioni appropriate per l'applicazione del client.
Anche se questa dimostrazione mostra il server licenze PlayReady che fornisce solo una chiave, è possibile che il server licenze fornisca uno stack di licenze in una sola risposta di licenza. È possibile includere più licenze in una transazione, con ogni licenza che fornisce una chiave se il contenuto è protetto con più chiavi o se il servizio vuole recapitare più chiavi in anticipo perché, ad esempio, il servizio sa che l'utente ascolterà otto tracce in una riga.
L'altra tecnologia fornita da PlayReady è un modo per archiviare la chiave e i diritti nel client, denominato License Store.
Lo Store licenze viene in genere chiamato HDS perché la struttura dell'archivio licenze è un archivio dati con hash. In un dispositivo possono essere presenti più tipi di negozi di licenze: un'applicazione può contenere il proprio HDS solo per garantire che l'HDS di una società non si trova nello stesso file di un'altra società HDS. È interamente lo sviluppatore client a scegliere questa scelta di progettazione. Ad esempio, usando PlayReady in Windows, Microsoft ha scelto di avere un HDS per Internet Explorer e un altro per Microsoft Edge per ogni sito, nonché uno per ogni app universale Windows.
Hds può essere archiviato in modo permanente, ad esempio nel disco rigido o nella memoria persistente del dispositivo, oppure può essere archiviato in modo non permanente, ad esempio in memoria non persistente. Pertanto, quando il server licenze rilascia una licenza, potrebbe impostare una proprietà della licenza che indica che la licenza non deve essere archiviata nel disco rigido del client, o nel caso di un set top box o telefono, che non deve essere archiviata in memoria persistente perché, come servizio, non si desidera che le licenze siano archiviate in memoria persistente. In tal caso, archiviare semplicemente hds in memoria nel contesto dell'applicazione lettore, quindi non appena l'utente chiude l'applicazione lettore, la licenza e i relativi diritti svaniranno.