Come eseguire la migrazione da versioni precedenti dell'infrastruttura a chiave pubblica e del server

Consigli per i servizi PlayReady

Microsoft consiglia i criteri di migrazione seguenti:

• Assicurarsi che un servizio venga aggiornato alla versione più recente di PlayReady SDK. In questo modo si garantirà la migliore compatibilità tra i dispositivi nuovi e legacy. Anche le versioni recenti di Server SDK hanno aggiunto miglioramenti significativi delle prestazioni e della stabilità. Si noti che non sono necessarie altre licenze o tariffe di licenza per eseguire l'aggiornamento al server PlayReady 4.0 più recente.

• Man mano che i nuovi dispositivi continuano la migrazione di PlayReady all'hardware (SoC), ci saranno sempre più dispositivi che inviano report a un servizio come PlayReady 3.0 e versioni successive e SL3000. Ad esempio, tutti i dispositivi Windows 10 ora segnalano come dispositivi PlayReady 3.0 e versioni successive. I servizi sono invitati a eseguire l'aggiornamento alla versione più recente dell'SDK del server per mantenere la compatibilità e sfruttare alcune delle nuove funzionalità.

• Usare le informazioni fornite in questo argomento come guida per gestire i casi perimetrali, ad esempio la gestione dei servizi di licenza legacy così com'è durante il supporto di nuovi dispositivi.

• Le licenze possono contattare askdrm@microsoft.com per ottenere l'accesso al sito di feedback per inviare domande sulla migrazione.

Consigli per i produttori di dispositivi PlayReady

È consigliabile che gli OEM aggiornino i dispositivi a PK4.0 rilasciati nell'ottobre 2017, ovvero l'unica versione che consente ai dispositivi di sfruttare le funzionalità più recenti implementate dai principali servizi multimediali.

Vantaggi	Contro - Punti di attenzione
Può supportare SL3000	Non compatibile con Server SDK 1.X
Può implementare funzionalità più recenti, ad esempio SecureStop, SecureDelete, MaxResDecode e così via
Codebase migliore
Assicurarsi che i nuovi criteri di licenza richiesti dai proprietari del contenuto possano essere applicati

Piano di aggiornamento OEM

1. Contattare i servizi e assicurarsi di eseguire la migrazione o aggiungere una versione di Server SDK 2.0 o successiva.

   • Verificare la versione dell'SDK del server.

   • Considerazioni ripetute per il servizio: nessun requisito aggiuntivo per le licenze di Microsoft e nessun costo aggiuntivo .

   • Se eseguono un servizio licenze basato su SDK server v2.0+, probabilmente saranno compatibili. Gli URL e gli scenari del servizio nella sezione successiva possono essere utili per i test di compatibilità.

   • Se eseguono un SDK server v1. Il server licenze basato su X può eseguire la migrazione del server licenze o aggiungere un server licenze più recente per i nuovi client, basato su server SDK 2.0+ (è consigliata la versione più recente).

2. Scaricare pk 4.0 da Microsoft.

3. Ottenere supporto dai partner Microsoft o direttamente da Microsoft inviando un messaggio di posta elettronica a AskDRM@microsoft.com.

4. Implementare PK 4.0 e rilasciare il prodotto.

Note sulle migrazioni per i servizi

Per garantire una compatibilità ottimale dei dispositivi, verificare che il server licenze esegua la versione più recente di Server SDK. L'SDK server più recente sarà in grado di distribuire licenze a tutti i client PlayReady indipendentemente dalla versione di Porting Kit usata. Se un client sviluppato con device porting kit 3.0 o versione successiva tenta di ottenere una licenza da un servizio licenze tramite PlayReady SDK 1.x, il servizio licenze restituirà un errore SOAP specifico del servizio generico. Il server porterà un'eccezione al log Windows notando che la richiesta non era presente nella catena di certificati client.

Migrazione di un servizio PlayReady a Server SDK 4.0

Un aggiornamento del servizio in genere non comporta modifiche al codice, ma solo una ricompilazione e la distribuzione delle librerie aggiornate. In alcuni casi, potrebbero essere presenti modifiche minime al codice a causa di alcune API deprecate. La ricompilazione e la distribuzione della libreria del gestore licenze devono essere trasparenti per i dispositivi che accedono al servizio.

La compilazione e la distribuzione di un gestore licenze aggiornato dovranno tenere in considerazione quanto segue:

• Il progetto dovrà rimuovere i riferimenti alle librerie PlayReady precedenti e farvi riferimento prima di ricompilare.

• Gli SDK server più recenti richiedono .NET 4.0 o versione successiva. Quando si aggiorna il gestore del servizio licenze da una versione precedente, ad esempio 1.52, il framework di destinazione dovrà essere aggiornato nelle proprietà del progetto a quello della versione 4.0 o successiva.

  

• Se il gestore legacy fa riferimento ad altre librerie destinate a una versione .NET inferiore alla 4.0, potrebbero essere necessari passaggi di migrazione aggiuntivi. Tuttavia, una libreria .NET può fare riferimento a una versione minore senza problemi in generale. Sarebbe opportuno esaminare l'opportunità di ricompilare le librerie a cui si fa riferimento alla versione del gestore o acquisire gli aggiornamenti della libreria per i componenti di terze parti.

• È necessario fare riferimento solo a Microsoft.Media.Drm.RMCore all'interno del progetto. Quando si distribuisce una soluzione, le altre DLL devono essere distribuite nella directory bin del sito Web. Non è necessario farvi riferimento all'interno del progetto, come nel caso degli SDK precedenti.

  

• Per il pool di applicazioni utilizzato dal servizio licenze è necessaria almeno la versione CLR .NET 4.0. Se il servizio licenze è in esecuzione 2.0 o versioni precedenti, è probabile che sia in esecuzione in una versione CLR .NET inferiore alla 4.0.

  

• La versione più recente di PlayReady Server SDK è supportata solo in Windows Server 2012 e versioni successive. Windows Server 2008 R2, tuttavia, non è noto che si verifichino problemi con Server SDK.

Supporto di versioni diverse di Server SDK per un servizio

Microsoft consiglia di eseguire la migrazione alla versione più recente dell'SDK subito dopo il rilascio. In alcuni casi, tuttavia, un servizio può voler eseguire più versioni di Server SDK. Ciò può essere dovuto alla gestione dei servizi legacy e dell'archivio e degli endpoint che non sono facilmente aggiornati. In questo caso, un servizio può puntare nuovi client a un servizio licenze aggiornato lasciando invariato il servizio legacy. Ad esempio, un servizio può avere diversi dispositivi legacy all'interno del proprio ecosistema che eseguono un client compilato con PlayReady PK 1.2. I nuovi dispositivi vengono sviluppati usando PlayReady PK 4.0. Il nuovo client deve puntare a un servizio licenze compilato con Server SDK 2.0 o versione successiva. Se entrambi i dispositivi legacy e nuovi usano la stessa applicazione ,ad esempio una piattaforma di app basata su HTML, sarà necessario aggiungere la logica all'applicazione per rilevare la versione del client. L'applicazione client può quindi indirizzare le richieste di licenza a un servizio licenze più recente.

La migrazione consigliata consiste nell'aggiornare il servizio licenze alla versione più recente di Server SDK. In questo modo è possibile garantire la compatibilità tra tutti i dispositivi per molti servizi. Un servizio dovrà testare i client per convalidare la compatibilità.

Se un servizio non vuole apportare modifiche a una configurazione client e servizio legacy, è consigliabile ospitare un secondo servizio licenze aggiornato alla versione più recente dell'SDK e che viene utilizzato dai client moderni.

Se un servizio usa una singola applicazione client in entrambi i dispositivi legacy (PlayReady 1.X) e nei dispositivi più recenti (PlayReady 3.0 o versione successiva), deve funzionare due server licenze PlayReady (PlayReady 1.X e PlayReady 3.0 o versione successiva) per servire le licenze a tutti questi dispositivi. L'applicazione può includere la logica per instradare le richieste al server licenze appropriato in base alla versione del client PlayReady sottostante oppure il servizio può usare un proxy di servizio che instrada le richieste provenienti da tutti questi dispositivi in un singolo URL al server licenze appropriato.

Questa operazione può essere eseguita in un proxy esaminando la richiesta di licenza. La versione PK verrà annotata nell'elemento .

L'elemento si trova all'interno della richiesta SOAP nell'elemento seguente:

<Challenge><LA><CLIENTINFO><CLIENTVERSION>3.1.0.1017</CLIENTVERSION> 

Supporto dei client basati su PK 3.0 o versione successiva con i servizi licenze legacy

Un dispositivo client sviluppato con PlayReady Device Porting Kit 3.0 o versione successiva funzionerà probabilmente con i servizi esistenti sviluppati con Server SDK 2.0 o versione successiva. Come indicato in precedenza, un servizio deve testare i client PK 3.0 o versioni successive per convalidare la compatibilità.

Se il dispositivo ha un certificato SL3000, SecurityLevel esposto tramite il certificato client nel gestore licenze segnala come 3000. Ciò può causare problemi con alcuni gestori di licenze se cercano un valore SecurityLevel specifico per distinguere tra dispositivi di produzione e di test.

La differenza tra SecurityLevels è comune per i servizi che forniscono accesso limitato al contenuto per i dispositivi di test per convalidare le licenze di riproduzione da un servizio live. Solo i dispositivi segnalati come SecurityLevel 2000 avrebbero le licenze di riproduzione distribuite per il contenuto commerciale. Il servizio genera un'eccezione specifica del servizio che genera un errore SOAP nel client.

Nell'esempio seguente, securityLevel viene archiviato nel certificato client per assicurarsi che si tratti di un dispositivo di produzione. Poiché è stato hardcoded a 2000, i dispositivi con il livello di sicurezza 3000 non verranno visti come dispositivi di produzione.

In questo esempio seguente viene aggiornato il controllo del livello di sicurezza per verificare se è maggiore o uguale a 2000. In questo modo si garantisce la compatibilità con i dispositivi SL3000.

Supporto delle funzionalità PlayReady 3.X e successive per i servizi

Oltre al nuovo livello di sicurezza DRM hardware, PlayReady 3.0 e versioni successive hanno introdotto anche una varietà di nuove funzionalità. Per sfruttare queste nuove funzionalità, il servizio dovrà prima determinare se il client è in grado di eseguire PlayReady 3.0 e versioni successive. La classe di certificato client supporta ora un metodo GetSupportedFeatures che restituirà una raccolta di funzionalità che consentono di definire i criteri all'interno del gestore. Se il client è stato sviluppato con device porting kit 3.0, avrà la proprietà SupportedFeature.PlayReady3Features nell'insieme. Nella raccolta sono disponibili funzionalità utili aggiuntive, ad esempio se il client usa un orologio protetto o un orologio anti-rollback.

Ecco un esempio di come rilevare se il dispositivo è un client PlayReady 3.0.

Dopo aver rilevato il gestore, è possibile aggiungere criteri come l'arresto sicuro, la scadenza della licenza in tempo reale e MaxResDecode, ad esempio.

Supporto di SL2000 e SL3000 nei servizi

PlayReady ha introdotto un nuovo livello di sicurezza SL3000 segnalato dai dispositivi che hanno soddisfatto il livello di sicurezza hardware PlayReady per l'esecuzione all'interno di un ambiente di esecuzione attendibile, come definito nelle regole di conformità e affidabilità. È comune che i servizi abbiano alcuni client report come SL2000 e altri report come SL3000. Ad esempio, in Windows, i dispositivi meno recenti aggiornati a Windows 10 possono segnalare come SL2000. I nuovi dispositivi Windows 10 segnalano come SL3000 dove la tecnologia DRM è stata incorporata nei chip più recenti.

Di seguito è riportato un esempio di servizio che fornisce criteri diversi in base al livello di sicurezza segnalato rispetto alla richiesta del client:

Un servizio determinerà la differenza tra i criteri tra i client DRM basati su software e i client DRM basati su hardware. Questi criteri possono essere basati sui requisiti di Studio. Ad esempio, uno studio potrebbe richiedere in futuro che il contenuto Ultra-HD o 4K sia limitato ai dispositivi che supportano la tecnologia DRM PlayReady basata su hardware.

I criteri PlayReady 3.0 e versioni successive per le risoluzioni possono essere eseguiti in due modi diversi. Un modo consiste nell'impostare i criteri MaxResDecode delle licenze SL2000 sui limiti consentiti forniti dal proprietario del contenuto. I dispositivi SL3000 non otterrebbero questa restrizione dei criteri. Un'altra opzione applicabile alle tecnologie di streaming adattive consiste nell'usare un KeyID diverso quando si proteggono le varie risoluzioni. Quando si rileva il livello di sicurezza, un servizio può quindi fornire solo licenze per le risoluzioni consentite per un client basato su software. Un client che segnala un livello di sicurezza di SL3000 otterrebbe licenze di riproduzione per tutte le risoluzioni. PlayReady ha introdotto una nuova intestazione DRM (v4.2.0.0 e versioni successive) per supportare questo secondo scenario abilitando più KeyID nello schema.

Vedere anche

Versioni del prodotto PlayReady

Come testare i client PlayReady con versioni di PlayReady Server SDK