Comment migrer à partir des versions précédentes du PK et du serveur
Recommandations pour PlayReady Services
Microsoft recommande les stratégies de migration suivantes :
Vérifiez qu’un service est mis à niveau vers la dernière version du Kit de développement logiciel (SDK) PlayReady. Cela offre la meilleure compatibilité entre les appareils nouveaux et hérités. Les versions récentes du Kit de développement logiciel (SDK) Server ont également ajouté des améliorations significatives des performances et de la stabilité. Notez qu’aucune licence ou licence supplémentaire n’est requise pour effectuer une mise à niveau vers le serveur PlayReady 4.0 le plus récent.
À mesure que de nouveaux appareils continuent la migration de PlayReady vers le matériel (SoC), il y aura de plus en plus d’appareils qui signalent à un service en tant que PlayReady 3.0 et versions ultérieures, et SL3000. Par exemple, tous les appareils Windows 10 signalent désormais en tant qu’appareils PlayReady 3.0 et versions ultérieures. Les services sont encouragés à effectuer une mise à niveau vers la dernière version du Kit de développement logiciel (SDK) serveur pour maintenir la compatibilité et tirer parti de certaines des nouvelles fonctionnalités.
Utilisez les informations fournies dans cette rubrique comme guide pour gérer les cas de périphérie, tels que la gestion des services de licence hérités en l’état tout en prenant en charge de nouveaux appareils.
Les titulaires de licence peuvent contacter askdrm@microsoft.com pour accéder à notre site de commentaires pour soumettre des questions de migration.
Recommandations pour les fabricants d’appareils PlayReady
Il est fortement recommandé que les fabricants OEM mettez à niveau leurs appareils vers PK4.0 publié en octobre 2017, qui est la seule version permettant aux appareils de tirer parti des dernières fonctionnalités implémentées par les principaux services multimédias.
| Avantages | Inconvénients - Points d’attention |
|---|---|
| Peut prendre en charge SL3000 | Non compatible avec le Kit de développement logiciel (SDK) Server 1.X |
| Peut implémenter les dernières fonctionnalités telles que SecureStop, SecureDelete, MaxResDecode, et ainsi de suite | |
| Meilleure base de code | |
| Vérifiez que les nouvelles stratégies de licence demandées par les propriétaires de contenu peuvent être appliquées |
Plan de mise à niveau OEM
Contactez vos services et assurez-vous qu’ils migrent tous ou ajoutent une version 2.0+ du Kit de développement logiciel (SDK) serveur.
Vérifiez sa version du Kit de développement logiciel (SDK) serveur.
Répétez les considérations relatives au service : aucune exigence de licence supplémentaire de Microsoft et aucun frais supplémentaire .
S’ils exécutent un service de licence basé sur le kit de développement logiciel (SDK) serveur v2.0+, ils seront probablement compatibles. Les URL de service et les scénarios de la section suivante peuvent aider à tester la compatibilité.
S’ils exécutent un Kit de développement logiciel (SDK) serveur v1. Serveur de licences X, ils peuvent migrer leur serveur de licences ou ajouter un serveur de licences plus récent pour les nouveaux clients, en fonction du SDK serveur 2.0+ (la dernière version est recommandée).
Téléchargez la version PK 4.0 à partir de Microsoft.
Obtenez du support auprès des partenaires de Microsoft ou directement de Microsoft en envoyant un e-mail à AskDRM@microsoft.com.
Implémentez PK 4.0 et publiez votre produit.
Notes de migration pour les services
Pour une compatibilité optimale des appareils, vérifiez que le serveur de licences exécute la dernière version du Kit de développement logiciel (SDK) serveur. Le SDK serveur le plus récent sera en mesure de fournir des licences à tous les clients PlayReady, quelle que soit la version du Kit de portage utilisée. Si un client développé avec le Kit de portage d’appareil 3.0 ou version ultérieure tente d’obtenir une licence auprès d’un service de licence à l’aide du Kit de développement logiciel (SDK) PlayReady 1.x, le service de licence retourne une erreur SOAP spécifique au service générique. Le serveur journalira une exception au journal Windows notant que le défi manquait à la chaîne de certificats client.
Migration d’un service PlayReady vers le Kit de développement logiciel (SDK) Server 4.0
Une mise à niveau de service n’implique généralement aucune modification du code, mais simplement une recompilation et un déploiement des bibliothèques mises à jour. Dans certains cas, il peut y avoir des modifications mineures du code en raison de certaines API déconseillées. La recompilation et le déploiement de la bibliothèque de gestionnaires de licences doivent être transparents pour les appareils accédant au service.
La compilation et le déploiement d’un gestionnaire de licences mis à jour doivent prendre en compte les éléments suivants :
Le projet devra supprimer les références aux anciennes bibliothèques PlayReady et les référencer avant de recompiler.
Les kits SDK serveur les plus récents nécessitent .NET 4.0 ou version ultérieure. Lors de la mise à niveau du gestionnaire de service de licence à partir d’une version antérieure telle que 1.52, le framework cible doit être mis à jour dans les propriétés du projet vers celle de la version 4.0 ou ultérieure.
Si le gestionnaire hérité fait référence à d’autres bibliothèques ciblant une version .NET inférieure à 4.0, il peut y avoir des étapes de migration supplémentaires. Toutefois, une bibliothèque .NET peut référencer une version inférieure sans problème en général. Il serait utile d’examiner l’opportunité de recompiler les bibliothèques référencées vers la version du gestionnaire ou d’acquérir des mises à jour de bibliothèque pour des composants tiers.
Seul Microsoft.Media.Drm.RMCore doit être référencé dans le projet. Lors du déploiement d’une solution, les autres DLL doivent être déployées dans le répertoire bin du site web. Ils n’ont pas besoin d’être référencés dans le projet, comme c’était le cas avec les kits SDK antérieurs.
Une version minimale du CLR .NET 4.0 est requise pour le pool d’applications utilisé par le service de licence. Si le service de licence exécutait la version 2.0 ou antérieure, il est probable qu’il s’exécute dans une version CLR .NET inférieure à 4.0.
Le dernier Kit de développement logiciel (SDK) PlayReady Server est pris en charge uniquement sous Windows Server 2012 et versions ultérieures. Windows Server 2008 R2, toutefois, n’est pas connu pour avoir des problèmes avec le Kit de développement logiciel (SDK) Server.
Prise en charge de différentes versions du Kit de développement logiciel (SDK) serveur pour un service
Microsoft vous recommande de migrer vers la dernière version du Kit de développement logiciel (SDK) peu après sa publication. Toutefois, dans certains cas, un service peut souhaiter exécuter plusieurs versions du Kit de développement logiciel (SDK) serveur. Cela peut être dû à la maintenance des services et points de terminaison hérités et d’archivage qui ne sont pas facilement mis à jour. Dans ce cas, un service peut pointer les nouveaux clients vers un service de licence mis à jour tout en laissant le service hérité inchangé. Par exemple, un service peut avoir un certain nombre d’appareils hérités au sein de son écosystème exécutant un client créé avec PlayReady PK 1.2. Leurs nouveaux appareils sont développés à l’aide de PlayReady PK 4.0. Le nouveau client doit pointer vers un service de licence créé avec le Kit de développement logiciel (SDK) Server 2.0 ou version ultérieure. Si les appareils hérités et nouveaux utilisent la même application (par exemple, une plateforme d’application HTML), la logique doit être ajoutée à l’application pour détecter la version du client. L’application cliente peut ensuite diriger les demandes de licence vers un service de licence plus récent.
La migration recommandée consiste à mettre à jour le service de licence vers la dernière version du Kit de développement logiciel (SDK) serveur. Cela peut assurer la compatibilité entre tous les appareils pour de nombreux services. Un service doit effectuer des tests entre les clients pour valider la compatibilité.
Si un service ne souhaite pas apporter de modifications à une configuration de client et de service hérité, il est recommandé d’héberger un deuxième service de licence qui a été mis à niveau vers la dernière version du SDK et qui est utilisé par les clients modernes.
Si un service utilise une application cliente unique sur les appareils hérités (PlayReady 1.X) et les appareils plus récents (PlayReady 3.0 ou version ultérieure), il doit utiliser deux serveurs de licences PlayReady (PlayReady 1.X et PlayReady 3.0 ou version ultérieure) pour distribuer des licences à tous ces appareils. L’application peut inclure la logique permettant d’acheminer les demandes vers le serveur de licences approprié en fonction de la version du client PlayReady sous-jacent, ou le service peut utiliser un proxy de service qui achemine les requêtes provenant de tous ces appareils sur une SEULE URL vers le serveur de licences approprié.
Cette opération peut être effectuée dans un proxy en inspectant la demande de licence. La version PK est notée dans l’élément.
L’élément se trouve dans le défi SOAP sous l’élément suivant :
<Challenge><LA><CLIENTINFO><CLIENTVERSION>3.1.0.1017</CLIENTVERSION>
Prise en charge des clients basés sur PK 3.0 ou version ultérieure avec des services de licence hérités
Un appareil client développé avec le Kit de portage d’appareil PlayReady 3.0 ou version ultérieure fonctionnera probablement avec les services existants développés avec le Kit de développement logiciel (SDK) Server 2.0 ou version ultérieure. Comme indiqué ci-dessus, un service doit tester les clients PK 3.0 ou ultérieur pour valider la compatibilité.
Si l’appareil a un certificat SL3000, securityLevel exposé via le certificat client dans le gestionnaire de licences signale 3000. Cela peut entraîner des problèmes avec certains gestionnaires de licences s’ils recherchent une valeur SecurityLevel spécifique pour différencier les appareils de production et de test.
La différenciation entre SecurityLevels est courante pour les services qui fournissent un accès limité au contenu pour les appareils de test afin de valider les licences de lecture à partir d’un service en direct. Seuls les appareils signalés comme SecurityLevel 2000 auraient des licences de lecture fournies pour le contenu commercial. Le service lève une exception spécifique au service qui entraînerait une erreur SOAP sur le client.
Dans l’exemple ci-dessous, SecurityLevel est archivé dans le certificat client pour s’assurer qu’il s’agit d’un appareil de production. Étant donné qu’il a été codé en dur à 2000, les appareils dont le niveau de sécurité est de 3 000 ne seront pas considérés comme des appareils de production.
Cet exemple suivant met à jour la vérification du niveau de sécurité pour déterminer s’il est supérieur ou égal à 2000. Cela garantit la compatibilité avec les appareils SL3000.
Prise en charge de PlayReady 3.X et des fonctionnalités supérieures pour les services
Outre le nouveau niveau de sécurité DRM matériel, PlayReady 3.0 et versions ultérieures ont également introduit une variété de nouvelles fonctionnalités. Pour tirer parti de ces nouvelles fonctionnalités, le service devra d’abord déterminer si le client est capable de PlayReady 3.0 et des fonctionnalités supérieures. La classe de certificat client prend désormais en charge une méthode GetSupportedFeatures qui retourne une collection de fonctionnalités pour faciliter la logique de définition de stratégies au sein du gestionnaire. Si le client a été développé avec le Kit de portage d’appareil 3.0, il aura la propriété SupportedFeature.PlayReady3Features dans la collection. Il existe des fonctionnalités supplémentaires utiles dans la collection, par exemple si le client utilise une horloge sécurisée ou une horloge anti-restauration.
Voici un exemple montrant comment détecter si l’appareil est un client PlayReady 3.0.
Une fois détecté, le gestionnaire peut ajouter des stratégies telles que Secure Stop, l’expiration de licence en temps réel et MaxResDecode, par exemple.
Prise en charge de SL2000 et SL3000 dans les services
PlayReady a introduit un nouveau niveau de sécurité SL3000 qui est signalé par les appareils qui ont atteint le niveau de sécurité matériel PlayReady pour s’exécuter dans un environnement d’exécution approuvé tel que défini dans les règles de conformité et de robustesse. Il sera courant que les services aient des rapports sur certains clients en tant que SL2000 et d’autres rapports en tant que SL3000. Par exemple, dans Windows, les anciens appareils qui ont été mis à niveau vers Windows 10 peuvent signaler en tant que SL2000. Les nouveaux appareils Windows 10 signalent que SL3000 où la GESTION des droits numériques a été incorporée dans les puces plus récentes.
Voici un exemple de service fournissant différentes stratégies en fonction du niveau de sécurité signalé par le défi du client :
Un service détermine comment les stratégies doivent différer entre les clients DRM basés sur logiciel et les clients DRM basés sur le matériel. Ces stratégies peuvent être pilotées par les exigences de Studio. Par exemple, un studio peut nécessiter à l’avenir que le contenu Ultra-HD ou 4K soit limité aux appareils qui prennent en charge la gestion des droits numériques en fonction du matériel.
Les stratégies PlayReady 3.0 et supérieures autour des résolutions peuvent être accomplies de deux façons différentes. L’une des méthodes consiste à définir la stratégie MaxResDecode des licences SL2000 sur les limites autorisées fournies par le propriétaire du contenu. Les appareils SL3000 n’obtiendraient pas cette restriction de stratégie. Une autre option applicable aux technologies de diffusion en continu adaptative consiste à utiliser un autre KeyID lors de la protection des différentes résolutions. Lors de la détection du niveau de sécurité, un service ne peut fournir que des licences pour les résolutions autorisées pour un client logiciel. Un client signalant un niveau de sécurité SL3000 obtiendrait des licences de lecture pour toutes les résolutions. PlayReady a introduit un nouvel en-tête DRM (v4.2.0.0 et versions ultérieures) pour prendre en charge ce dernier scénario en activant plusieurs KEYID dans le schéma.