Ben heu, oui mais non. Le but des DRM n'est pas vraiment d'empêcher les utilisateurs de lire leurs MP3 actuels, c'est bien plus complexe que ça.
Imagines que tu télécharges, sur un site web, un document protégé par DRM. Le site web n'acceptera de te délivrer le document que si l'application qui le télécharge s'authentifie numériquement comme une application de « confiance »[1]. L'application en question, outre une gestion stricte des instructions contenues dans le document (ne pas permettre de la copier si le document l'interdit, ne la jouer que N fois et ensuite la détruire, etc), écrira les données du document dans une zone identifiée comme de « confiance » dans le disque dur. Cette zone, les applications non-signées, pas plus que ton Linux en dual-boot (la protection est gérée au niveau hardware) ne pourront y accéder. Vu que la clé privée de l'application signée est aussi protégée de manière matérielle, impossible de la récupérer pour l'utiliser ailleurs.
Quid des émulateurs / virtualisateurs, alors? Ben, vu que la protection est gérée au niveau matériel, le périphérique de « confiance » (disque-dur, lecteur externe, etc) n'acceptera de délivrer les données protégées qu'à une application de « confiance » (typiquement, un gestionnaire de périphériques signé). Laquelle, à son tour, ne pourra délivrer les données qu'à une application selon le même mécanisme, etc. On crée ainsi une « chaîne de confiance », d'où les données, sauf exploitation du bug, ne pourront pas sortir. Si, dans cette chaîne, on intercale un virtualisateur, ou tout dispositif externe brisant la chaîne (kernel non-signé, débugger, etc), les données s'arrêteront là où le dispositif a été interposé; l'élément de plus bas niveau refusant de fournir les données à ce dispositif.
Quid des interpréteurs, maintenant? Ben, même problème. Un interpréteur de « confiance » ne pourra faire transiter de données « protégées » que vers un script signé.
On peut, de plus, imaginer des classe de « confiance » apparaissant à un niveau ou à un autre de la chaîne. Il n'est pas impossible qu'une application puisse être signée comme ayant le droit d'ouvrir certains types de documents, et pas d'autres. Je n'ai pas lu le détail des spécifications.
Enfin bon, dans tous les cas, pour les virus, oublie; c'est de la propagande marketing et même Microsoft dit bien que ça n'apportera rien à ce niveau. Un système de ce genre n'apporte rien de plus par rapport à un système de protection traditionnel. L'« innovation » de ce système est uniquement de « protéger » un équipement contre ses utilisateurs légitimes, pas contre d'éventuelles attaques externes.
[1]: Noter les guillements, qui traduisent la non-adéquation du terme « confiance ». On peut logiquement considérer que celui qui doit avoir confiance en un équipement ou un logiciel, c'est celui qui en a l'usage, et non des tierces personnes. Ce qui est de confiance pour les uns est déloyal pour les autres.
[^] # Re: Accessoirement Palladium est techniquement irréaliste
Posté par Gruik Man . En réponse à la dépêche TCPA/Palladium dans le Monde. Évalué à 5.
Imagines que tu télécharges, sur un site web, un document protégé par DRM. Le site web n'acceptera de te délivrer le document que si l'application qui le télécharge s'authentifie numériquement comme une application de « confiance »[1]. L'application en question, outre une gestion stricte des instructions contenues dans le document (ne pas permettre de la copier si le document l'interdit, ne la jouer que N fois et ensuite la détruire, etc), écrira les données du document dans une zone identifiée comme de « confiance » dans le disque dur. Cette zone, les applications non-signées, pas plus que ton Linux en dual-boot (la protection est gérée au niveau hardware) ne pourront y accéder. Vu que la clé privée de l'application signée est aussi protégée de manière matérielle, impossible de la récupérer pour l'utiliser ailleurs.
Quid des émulateurs / virtualisateurs, alors? Ben, vu que la protection est gérée au niveau matériel, le périphérique de « confiance » (disque-dur, lecteur externe, etc) n'acceptera de délivrer les données protégées qu'à une application de « confiance » (typiquement, un gestionnaire de périphériques signé). Laquelle, à son tour, ne pourra délivrer les données qu'à une application selon le même mécanisme, etc. On crée ainsi une « chaîne de confiance », d'où les données, sauf exploitation du bug, ne pourront pas sortir. Si, dans cette chaîne, on intercale un virtualisateur, ou tout dispositif externe brisant la chaîne (kernel non-signé, débugger, etc), les données s'arrêteront là où le dispositif a été interposé; l'élément de plus bas niveau refusant de fournir les données à ce dispositif.
Quid des interpréteurs, maintenant? Ben, même problème. Un interpréteur de « confiance » ne pourra faire transiter de données « protégées » que vers un script signé.
On peut, de plus, imaginer des classe de « confiance » apparaissant à un niveau ou à un autre de la chaîne. Il n'est pas impossible qu'une application puisse être signée comme ayant le droit d'ouvrir certains types de documents, et pas d'autres. Je n'ai pas lu le détail des spécifications.
Enfin bon, dans tous les cas, pour les virus, oublie; c'est de la propagande marketing et même Microsoft dit bien que ça n'apportera rien à ce niveau. Un système de ce genre n'apporte rien de plus par rapport à un système de protection traditionnel. L'« innovation » de ce système est uniquement de « protéger » un équipement contre ses utilisateurs légitimes, pas contre d'éventuelles attaques externes.
[1]: Noter les guillements, qui traduisent la non-adéquation du terme « confiance ». On peut logiquement considérer que celui qui doit avoir confiance en un équipement ou un logiciel, c'est celui qui en a l'usage, et non des tierces personnes. Ce qui est de confiance pour les uns est déloyal pour les autres.