Meilleures pratiques pour les stratégies de licence
Cette section décrit les meilleures pratiques pour la programmation des stratégies de licence lors de l’utilisation des technologies PlayReady.
Utilisation de BeginDate avec EndDate
L’un des nombreux modèles métier pris en charge par PlayReady est la location de contenu : contenu qui ne peut être utilisé que pendant une période limitée (par exemple, le contenu peut être utilisé jusqu’à 15h EST, 15 octobre 2018). Pour ce faire, il est possible d’émettre aux clients une licence PlayReady avec endDate défini sur l’heure et la date d’expiration de la licence.
Un EndDate est suffisant pour créer une licence de location ; toutefois, il est préférable d’inclure également un BeginDate dans la licence. Un BeginDate spécifie que le contenu associé ne peut pas être utilisé avant la date spécifiée. La combinaison d’un BeginDate avec EndDate est une impedance naturelle pour les attaques de restauration d’horloge, où les utilisateurs sauvegardent et restaurent l’intégralité du magasin de données PlayReady pour éviter les événements de restauration d’horloge.
Prenons l’exemple suivant :
La date est 08/01/18 : l’utilisateur acquiert licence1 pour Content1. License1 a EndDate=08/30/18.
La date est 09/01/18 : l’utilisateur acquiert licence2 pour Content2. License2 a EndDate=09/30/18.
L’utilisateur effectue une copie du magasin de données PlayReady.
Avant de lire Content1 ou Content2, l’utilisateur rétablit l’horloge sur 18/08/08/ 18, restaure la copie du magasin de données PlayReady. Les deux éléments de contenu peuvent être lus.
Considérez maintenant le même exemple de base, mais avec BeginDates dans les licences :
La date est 08/01/18 : l’utilisateur acquiert License1 pour Content1. License1 a BeginDate=08/01/18, EndDate=08/30/18.
La date est 09/01/18 : l’utilisateur acquiert licence2 pour Content2. License2 a BeginDate=09/01/18, EndDate=09/30/18.
L’utilisateur effectue une copie du magasin de données PlayReady.
Avant de lire Content1 ou Content2, l’utilisateur rétablit l’horloge à une date antérieure au 18/08/08/ 18, restaure la copie du magasin de données PlayReady. Seul Content1 sera lu.
Cet exemple montre comment BeginDate contribue naturellement à réduire la faisabilité du magasin de données en cours de restauration pour contourner la stratégie de licence. Un utilisateur peut effectuer davantage de copies du magasin de données pour contourner BeginDate, mais à mesure que le nombre de fichiers de contenu augmente, la gestion de tous les magasins de données nécessaires pour contourner la stratégie de licence augmente en proportion, ce qui rend une attaque beaucoup moins réalisable.
En résumé, lors de la spécification d’un EndDate dans une licence PlayReady, il est recommandé d’inclure également un BeginDate.
Définition d’une valeur BeginDate qui fonctionne pour le client
Lors de l’ajout d’un BeginDate à une licence, il est recommandé de le définir un peu dans le passé, pour les clients PlayReady version 1 ou 2. La raison en est qu’il peut y avoir une différence d’horloge mineure entre le serveur générant cette licence et le client qui le reçoit, et l’intention du serveur est que le client peut utiliser la licence dès que le client le reçoit.
Pour les clients PlayReady 3 et versions ultérieures, le client envoie sa valeur d’horloge au serveur de licence le long de la demande de licence, et le serveur peut définir BeginDate et d’autres restrictions de temps en ce qui concerne cette valeur, sous la condition qu’il est proche de la valeur de temps connue du serveur de licences.
Un exemple classique avec un client PlayReady version 2 serait :
Un utilisateur loue du contenu le vendredi 5 janvier 2018 à 18h00 sur un téléphone Android exécutant une application basée sur PlayReady 2.5.
L’application Android lance une demande de licence au serveur de licences. L’horloge du téléphone indique 17 h 56 et l’horloge du serveur de licences est le 18 h 00.
Le serveur de licences reçoit la demande de licence, détecte que le client est la version 2 et génère la licence avec :
Jouer à droite
Heure de début = heure du serveur local moins 5 minutes = 5 janvier 2018 à 17h55
Délai d’expiration, expiration après le premier lecture, autres restrictions appropriées telles que les protections de sortie
Le serveur de licences renvoie la licence au client.
Le client démarre la lecture. L’horloge du téléphone est toujours 7:56PM et est passée de la date de début de la licence qui est 7:55PM, de sorte que la lecture peut réellement démarrer immédiatement.
Un exemple classique avec un client PlayReady version 3 serait :
Un utilisateur loue du contenu le vendredi 5 janvier 2018 à 18h00 sur un ordinateur Windows 10 exécutant une application UWP.
L’application UWP lance une demande de licence au serveur de licences. L’horloge du PC indique 17h56 et l’horloge du serveur de licences est à 18h00.
Le serveur de licences reçoit la demande de licence, détecte que le client PlayReady est la version 3 et recherche la valeur de l’horloge du client :
Si la valeur de l’horloge du client n’est pas supérieure à la valeur d’horloge du serveur de licences supérieure à 1 heure, poursuivez et générez la licence.
Si ce n’est pas le cas, refusez la demande de licence et envoyez un message à l’application cliente pour demander que l’horloge soit définie sur la valeur appropriée.
Le serveur de licences génère la licence avec :
Jouer à droite
Heure de début = heure du client contenue dans la demande de licence = 5 janvier 2018 à 17h56
Délai d’expiration, expiration après le premier lecture, autres restrictions appropriées telles que les protections de sortie
Le serveur de licences renvoie la licence au client.
Le client démarre la lecture. L’horloge du PC est toujours 7:56PM et égale ou antérieure à la date de début de la licence, qui est 7:56PM, afin que la lecture puisse réellement démarrer immédiatement.
Restrictions de temps dans les licences d’abonnement
PlayReady prend en charge un modèle métier d’abonnement dans lequel les utilisateurs paient des frais mensuels en retour pour accéder à un catalogue de contenu volumineux proposé par le service.
Dans ce scénario, les serveurs de licences PlayReady émettent des licences feuilles pour chaque fichier de contenu et une seule licence racine. Pour que PlayReady accède au contenu, sa licence feuille et la licence racine (la chaîne de licences) sont nécessaires. Les deux licences doivent contenir l’action exécutée sur le contenu (par exemple, lire) et les deux licences doivent être valides (non expirées, etc.).
Étant donné qu’il n’existe qu’une seule licence racine et potentiellement des centaines ou des milliers de licences feuilles pour un catalogue de contenu particulier, les licences feuille doivent inclure très peu de restrictions (le cas échéant) et la licence racine doit contenir des restrictions de temps et être actualisée régulièrement (par exemple, mensuelle). Lorsqu’un abonnement est sur le point d’expirer, le serveur de licences doit émettre une seule licence et tout le contenu est mis à jour avec la nouvelle date d’expiration effective. Si la stratégie dans les licences feuille contient une stratégie basée sur le temps, toutes les licences feuilles doivent être réécrites pour empêcher l’expiration du contenu, ce qui serait une exigence de performances importante pour les serveurs.
En résumé, si le contenu est censé expirer à l’aide de chaînes de licences, seule la licence racine doit contenir la stratégie basée sur le temps.