Procedure consigliate per i criteri di licenza

Questa sezione descrive le procedure consigliate per la programmazione dei criteri di licenza quando si usano tecnologie PlayReady.

Uso di BeginDate con EndDate

Uno dei numerosi modelli di business supportati da PlayReady è il noleggio di contenuti, ovvero il contenuto che può essere usato solo per un periodo limitato(ad esempio, il contenuto può essere usato fino alle 15:00 EST, 15 ottobre 2018). Questa operazione viene eseguita rilasciando ai client una licenza PlayReady con EndDate impostato sull'ora e la data in cui la licenza scade.

Un EndDate è sufficiente per creare una licenza di noleggio; tuttavia, è consigliabile includere anche beginDate nella licenza. BeginDate specifica che il contenuto associato non può essere utilizzato prima della data specificata. La combinazione di beginDate con EndDate è un'impedance naturale per gli attacchi di rollback di clock, in cui gli utenti esepreno e ripristinano l'intero archivio dati PlayReady per evitare eventi di rollback dell'orologio.

Si consideri l'esempio seguente:

• La data è 08/01/18 : l'utente acquisisce La licenza1 per Content1. License1 ha EndDate=08/30/18.

• La data è 09/01/18 : l'utente acquisisce La licenza2 per Content2. License2 ha EndDate=09/30/18.

• L'utente crea una copia dell'archivio dati PlayReady.

• Prima di riprodurre Content1 o Content2, l'utente imposta l'orologio su 08/01/18, ripristina la copia dell'archivio dati PlayReady. Entrambi i contenuti possono essere riprodotti.

Si consideri ora lo stesso esempio di base, ma con BeginDates nelle licenze:

• La data è 08/01/18 : l'utente acquisisce License1 per Content1. License1 ha BeginDate=08/01/18, EndDate=08/30/18.

• La data è 09/01/18: l'utente acquisisce License2 per Content2. License2 ha BeginDate=09/01/18, EndDate=09/30/18.

• L'utente crea una copia dell'archivio dati PlayReady.

• Prima di riprodurre Content1 o Content2, l'utente imposta l'orologio su una data precedente all'18/08/08/08, ripristina la copia dell'archivio dati PlayReady. Verrà riprodotto solo Content1.

Questo esempio mostra in che modo BeginDate contribuisce naturalmente a ridurre la fattibilità dell'archivio dati ripristinato per aggirare i criteri di licenza. Un utente può creare più copie dell'archivio dati per aggirare BeginDate, ma man mano che il numero di file di contenuto aumenta, la gestione di tutti gli archivi dati necessari per aggirare i criteri di licenza aumenta in proporzione, rendendo un attacco molto meno fattibile.

In sintesi, quando si specifica un endDate in una licenza PlayReady, è consigliabile includere anche beginDate.

Impostazione di un valore BeginDate che funziona per il client

Quando si aggiunge un beginDate a una licenza, è consigliabile impostarlo un po' in passato, per i client PlayReady versione 1 o 2. Il motivo è che potrebbe esserci una differenza di clock minore tra il server che genera questa licenza e il client che lo riceve e la finalità del server è che il client può usare la licenza non appena il client lo riceve.

Per i client PlayReady 3 e versioni successive, il client invia il relativo valore di clock al server licenze lungo la richiesta di licenza e il server può impostare BeginDate e altre restrizioni temporali rispetto a tale valore, a condizione che sia vicino al valore di ora noto al server licenze.

Un esempio tipico con un client PlayReady versione 2 è:

1. Un utente noleggia contenuti il venerdì 5 gennaio 2018 circa le 18:00, su un telefono Android che esegue un'app basata su PlayReady 2.5.

2. L'app Android avvia una richiesta di licenza al server licenze. L'orologio del telefono indica 7:56PM e l'orologio del server licenze è alle 8:00.

3. Il server licenze riceve la richiesta di licenza, rileva che il client è la versione 2 e genera la licenza con:

   • Gioca a destra

   • Ora di inizio = ora locale del server meno 5 minuti = 5 gennaio 2018 alle 17:55

   • Ora di scadenza, scadenza dopo la prima riproduzione, altre restrizioni corrette come le protezioni di output

   4. Il server licenze invia nuovamente la licenza al client.

   5. Il client avvia la riproduzione. L'orologio del telefono è ancora 7:56PM ed è passato il BeginDate della licenza, che è 7:55PM, in modo che la riproduzione possa effettivamente iniziare immediatamente.

Un esempio tipico con un client PlayReady versione 3 è:

1. Un utente noleggia contenuti il venerdì 5 gennaio 2018 circa le 18:00, su un computer Windows 10 che esegue un'app UWP.

2. L'app UWP avvia una richiesta di licenza al server licenze. L'orologio del PC indica 7:56PM e l'orologio del server licenze è alle 8:00.

3. Il server licenze riceve la richiesta di licenza, rileva che il client PlayReady è la versione 3 e verifica il valore dell'orologio client:

   • Se il valore dell'orologio client non è più lontano dal valore dell'orologio del server licenze di 1 ora, procedere e generare la licenza.

   • In caso contrario, negare la richiesta di licenza e inviare un messaggio all'app client per richiedere che l'orologio venga impostato sul valore corretto.

4. Il server licenze genera la licenza con:

   • Gioca a destra

   • Ora di inizio = Ora client contenuta nella richiesta di licenza = 5 gennaio 2018 alle 17:56

   • Ora di scadenza, scadenza dopo la prima riproduzione, altre restrizioni corrette come le protezioni di output

   4. Il server licenze invia nuovamente la licenza al client.

   5. Il client avvia la riproduzione. L'orologio del PC è ancora 7:56PM e uguale o superato il BeginDate della licenza, ovvero le 17:56, in modo che la riproduzione possa essere avviata immediatamente.

Restrizioni temporali nelle licenze di sottoscrizione

PlayReady supporta un modello aziendale di sottoscrizione in cui gli utenti pagano una tariffa mensile per l'accesso a un catalogo di contenuti di grandi dimensioni offerto dal servizio.

In questo scenario, i server licenze PlayReady rilasciano licenze foglia per ogni file di contenuto e una singola licenza radice. Per consentire a PlayReady di accedere al contenuto, sono necessarie sia la licenza foglia che la licenza radice (la catena di licenze). Entrambe le licenze devono contenere l'azione eseguita sul contenuto (ad esempio, riprodurre) e entrambe le licenze devono essere valide (non scadute e così via).

Poiché esiste una sola licenza radice e potenzialmente centinaia o migliaia di licenze foglia per qualsiasi catalogo di contenuti specifico, le licenze foglia devono includere pochissime restrizioni (se presenti) e la licenza radice deve contenere restrizioni temporali e essere aggiornate periodicamente (ad esempio, mensilmente). Quando una sottoscrizione sta per scadere, il server licenze deve rilasciare una sola licenza e tutto il contenuto verrà aggiornato con la nuova data di scadenza effettiva. Se i criteri nelle licenze foglia contengono criteri basati sul tempo, tutte le licenze foglia devono essere ri-rilasciate per impedire la scadenza del contenuto, che sarebbe un requisito di prestazioni elevato per i server.

In sintesi, se il contenuto deve scadere usando le catene di licenze, solo la licenza radice deve contenere i criteri basati sul tempo.