Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
In genere, Microsoft PlayReady protegge il contenuto fornendo licenze per i file multimediali. Non è necessario nascondere i file, renderli inaccessibili o mettere in atto 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 ad alta sicurezza. Tuttavia, copiare un file e assegnarlo a un amico non abiliterà tale amico a usare il file se è protetto da PlayReady. Per usare un file multimediale, gli utenti hanno bisogno 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 include alcuni server per lo streaming del video (rete di distribuzione del contenuto). Esistono anche alcuni server che consentono agli utenti di esplorare il contenuto e scegliere il contenuto da 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 possono essere applicazioni Windows, applicazioni smartphone o dispositivi specifici, ad esempio set top box, ricevitori di rete e così via. Alcuni di questi client possono essere dotati di un client integrato PlayReady nei propri 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 è incentrato sulle 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 recapita le chiavi che proteggono il contenuto in un modulo protetto tramite una rete aperta. La seconda cosa che PlayReady fa è fornire diritti e le relative restrizioni al client. Con PlayReady, il servizio ha la possibilità di fornire una chiave per la riproduzione del contenuto, ma, ad esempio, consente solo 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 dei diritti con la chiave.
PlayReady offre anche un modo per archiviare in modo più sicuro la chiave del contenuto sul lato client, in modo che il client possa usare tale chiave per decrittografare il contenuto per il rendering, ma non consentire il salvataggio del 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 anche che i client eselaborino correttamente le restrizioni rilevate in una licenza. Pertanto, se un client riceve istruzioni per usare la chiave di contenuto 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 gestione delle licenze 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 proprio crittografatore di contenuto che genera una nuova chiave di contenuto che verrà usata per crittografare il contenuto. Questa chiave del contenuto verrà successivamente distribuita dal server licenze PlayReady al client per consentire la decrittografia del contenuto e la visualizzazione per l'utente. Insieme alla chiave del contenuto, che è un valore privato, i servizi di crittografia associano anche un identificatore di chiave (KeyID), ovvero un GUID, alla chiave del contenuto. 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 keyID 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 in chiaro nell'intestazione del file di contenuto.
A questo punto, l'audio e il video verranno crittografati con KeyID 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 farà probabilmente è autenticare l'utente al servizio, in genere fornendo un nome utente e una password, ma qualsiasi altro meccanismo per l'autenticazione dell'utente e del dispositivo va bene. 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 come 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 individua 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 cosa che il server licenze esegue è verificare che il client/utente abbia il 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 film, 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 ribadire, 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ò recapitare la licenza. La risposta della licenza PlayReady protetta include il valore della chiave e un elenco di diritti e restrizioni appropriate per il client da applicare.
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 in anticipo più chiavi 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 Archivio licenze.
The License Store is typically called the HDS because the structure of the License Store is a *hashed data store*. There can be multiple types of License Stores on a device — one application could contain its own HDS just to ensure that one company's HDS is not in the same file as another company's HDS. It is entirely up to the client developer to make this design choice. For example, using PlayReady on Windows, Microsoft chose to have one HDS for Internet Explorer and another for Microsoft Edge per site, as well as one for each Windows Universal App.
The HDS can be stored in a persistent way, such as on the hard drive or persistent memory of the device, or it can be stored in a non-persistent way, such as in non-persistent memory. Therefore, when the License Server issues a license, it could set a property of the license indicating that the license should not be stored on the hard drive of the client, or in the case of a set top box or phone, that it should not be stored in persistent memory because, as a service, you don't want to have your licenses stored in persistent memory. In that case, just store the HDS in memory in the context of the player application, so as soon as the user closes the player application, the license and its rights will vanish.