Transfert des ID de contenu DRM
Le pilote système DRMK démêche un flux de lecture audio contenant du contenu protégé. DRMK implémente un filtre KS qui prend un flux d’entrée contenant les données brouillées, les démêche et alimente le flux non brouillé dans un chemin de données constitué d’un certain nombre de modules résidant dans le noyau. Ces modules peuvent être des filtres KS ou d’autres types de pilotes. Le chemin des données se termine généralement par un appareil de rendu audio qui convertit le contenu numérique en signal analogique qui peut être lu via des haut-parleurs.
Avant d’autoriser le contenu non brouillé à entrer dans le chemin des données, DRMK vérifie que le chemin des données est sécurisé. Pour ce faire, DRMK authentifie chaque module dans le chemin des données, en commençant par le module à la amont fin du chemin d’accès aux données et en aval à l’autre extrémité du chemin d’accès aux données. La figure suivante illustre ce processus.
Dans la figure précédente, les flèches unie représentent le chemin des données, et les flèches en pointillés représentent les communications nécessaires pour vérifier que le chemin des données est sécurisé. Les données non brouillées entrent dans le chemin d’accès uniquement une fois que DRMK a terminé l’authentification de tous les modules de ce chemin.
Une fois que DRMK authentifie chaque module, ce module fournit à DRMK des informations sur le module suivant dans le chemin des données afin qu’il puisse également être authentifié. Chaque module étant authentifié, il reçoit l’ID de contenu DRM qui identifie le flux.
À partir de la amont fin du chemin de données sécurisé, DRMK transfère l’ID de contenu au module A, qui à son tour transfère l’ID de contenu au module B. Ce processus se poursuit jusqu’à ce que l’ID de contenu soit transféré au module Z, le dernier module du chemin d’accès aux données sécurisées.
La figure suivante montre une paire de modules adjacents dans le chemin des données.
Le module côté amont appelle l’une des fonctions DRM suivantes pour fournir à DRMK des informations sur le module en aval et transférer l’ID de contenu à ce module :
DrmForwardContentToDeviceObject
Chacune de ces fonctions de « transfert » fournit à DRMK l’ID de contenu DRM qui identifie le flux protégé et les informations dont DRMK a besoin pour authentifier le module en aval. Le choix de l’une de ces trois fonctions à appeler dépend du type d’interface que les deux modules adjacents utilisent pour communiquer entre eux quand ils gèrent le transfert de contenu protégé :
Si le module amont appelle IoCallDriver pour communiquer avec le module en aval, le module en aval fait partie d’un pilote WDM. Dans ce cas, le module amont appelle DrmForwardContentToDeviceObject pour fournir à DRMK l’objet d’appareil représentant le module en aval. DRMK utilise l’objet d’appareil pour authentifier le module en aval.
Si les deux modules communiquent via une interface COM que le module en aval implémente, le module amont appelle DrmForwardContentToInterface. Cet appel fournit DRMK avec un pointeur vers l’interface COM du module en aval. DRMK appelle uniquement les méthodes IUnknown dans cette interface et ne fait aucune hypothèse sur les autres méthodes, bien que les deux modules eux-mêmes doivent s’entendre sur ce que font ces méthodes. DRMK vérifie que le point d’entrée de chaque méthode dans l’interface appartient à un module authentifié. Si les points d’entrée sont distribués entre plusieurs modules, DRMK authentifie tous ces modules.
Si les deux modules n’utilisent ni une interface COM ni la fonction IoCallDriver pour communiquer, le module amont appelle DrmAddContentHandlers pour fournir à DRMK une liste de points d’entrée aux « gestionnaires de contenu » implémentés dans le module en aval. DRMK n’appelle pas les gestionnaires de contenu et n’émet aucune hypothèse concernant les fonctions qu’ils exécutent. DrmK authentifie toutefois le ou les modules dans lesquels résident les points d’entrée.
Une fois authentifié, le module en aval nécessite les informations suivantes :
ID de contenu DRM qui identifie le flux contenant le contenu protégé. Le module a besoin de cet ID pour informer DRMK de tout module, plus en aval, auquel il prévoit d’envoyer le contenu protégé.
Droits de contenu DRM associés au contenu protégé. Le module nécessite les droits de contenu pour appliquer le niveau de sécurité approprié.
Chacune des trois fonctions de transfert fournit ces informations au module d’une manière légèrement différente :
La fonction DrmForwardContentToDeviceObject envoie une KSPROPERTY_DRMAUDIOSTREAM_CONTENTID demande set-property à l’objet d’appareil du module en aval. Cette requête transfère l’ID de contenu et les droits de contenu du flux au module en aval.
La fonction DrmForwardContentToInterface interroge l’interface COM du module en aval pour l’interface IDrmAudioStream . Si la requête réussit, la fonction appelle la méthode IDrmAudioStream ::SetContentId pour transférer l’ID de contenu et les droits de contenu au module en aval.
Dans le cas de la fonction DrmAddContentHandlers, l’appelant (module amont) est chargé de transférer l’ID de contenu et les droits de contenu du flux vers le module en aval. Une fois que DrmAddContentHandlers retourne un code de réussite indiquant que le module en aval a été authentifié, le module amont transmet l’ID de contenu et les droits de contenu au module en aval en appelant l’un de ses gestionnaires de contenu.
Si le module amont est un pilote miniport WaveCyclique ou WavePci, il peut appeler indirectement la fonction DRM appropriée via l’une des méthodes suivantes :
IDrmPort2 ::ForwardContentToDeviceObject
IDrmPort ::ForwardContentToInterface
IDrmPort2 ::AddContentHandlers
Pour plus d’informations, consultez Fonctions DRM.
Par souci de simplicité, la discussion précédente suppose que chaque module du chemin d’accès aux données accepte un flux à partir d’une source unique et transfère ce flux à un module en aval au plus. En fait, un module peut transférer un flux à plusieurs modules en aval, mais il doit d’abord authentifier chaque module en aval en appelant l’une des trois fonctions de transfert. De même, un module peut combiner plusieurs flux d’entrée, mais il doit respecter les droits de contenu des flux d’entrée en fournissant le niveau de protection approprié au flux de sortie mixte. Pour plus d’informations, consultez la présentation de la fonction DrmCreateContentMixed dans Les ID de contenu et les droits de contenu.
Un chemin de données sécurisé classique se compose du pilote système KMixer suivi d’un filtre d’ondes qui représente le périphérique de rendu audio. Le filtre est implémenté en tant que pilote miniport WaveCyclique ou WavePci en combinaison avec le pilote de port correspondant. Pour vérifier que le chemin des données est sécurisé, DRMK transfère l’ID de contenu à KMixer, qui à son tour transfère l’ID de contenu au filtre. Le pilote de port, qui implémente la fonctionnalité de filtre générique, reçoit l’ID de contenu et le transfère au pilote miniport. Plus précisément, le pilote de port appelle la fonction DrmForwardContentToInterface pour transférer l’ID de contenu à l’objet de flux que le pilote miniport a instancié pour représenter la broche de sortie d’onde sur le périphérique de rendu audio. L’une des valeurs de paramètre de cet appel est un pointeur vers l’interface IMiniportWaveCycliqueStream ou IMiniportWavePciStream de l’objet de flux. Par le biais de cette interface, la fonction interroge l’objet stream pour son interface IDrmAudioStream et appelle la méthode SetContentId de cette interface.
Pour plus d’informations, consultez les implémentations de la méthode SetContentId dans l’exemple de pilote Sysvad, qui est décrit dans Exemples de pilotes audio.
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour