Existe-t-il une solution DRM open source?
Existe-t-il une structure/bibliothèque DRM open source, bien documentée et utilisée?
Je veux écrire un cadre pour acheter et vendre des trucs numériques, où je veux mettre en œuvre, d'une manière ou d'une autre, pour que le vendeur ait la possibilité de verrouiller les fichiers avec une sorte de DRM, où seuls les ordinateurs autorisés pourraient l'ouvrir (quelque chose comme iTunes FairPlay).
Cela peut, et doit probablement, impliquer de contacter mon serveur avec certaines informations de connexion.
D'un autre côté, je veux que le client soit open source, et probablement aussi le serveur .. est-ce même possible? La sécurité par l'obscurité ne fonctionne pas, mais le DRM n'est pas exactement la "sécurité" ...
Tout ce que j'ai pu trouver est cette discussion sur slashdot avec exactement le même problème , mais elle s'est terminée par "DRM IS BAD" et le projet DReaM de Sun, mais je ne sais pas comment se rendre au code réel/utilisation du framework sur leur site .
Si vous pensez que l'Open Sourced DRM n'est pas possible, dites-le-moi.
Cela prétend être une implémentation open source de OMA DRM2. Je suppose qu'il contient les composants logiciels nécessaires pour construire le serveur et le client, laissant le matériel comme exercice au lecteur:
http://sourceforge.net/projects/openipmp
La licence est MPL, qui est une licence FOSS non compatible GPL.
Je n'ai aucune expérience de cette implémentation, mais un peu de OMA DRM, et il semblait à l'époque être un schéma DRM fonctionnel, autant que n'importe quel schéma DRM est réalisable. La norme OMA DRM est bien documentée et est (ou du moins a été) largement utilisée par l'industrie de la téléphonie mobile.
Le problème fondamental avec le DRM open-source est que, bien que tous les algorithmes et le code source puissent être publiés sans nuire au système, l'émetteur des droits doit "faire confiance" aux dispositifs clients pour respecter les droits, c'est-à-dire ne rien faire d'interdit. Ceci est incompatible avec FOSS, qui dit que l'utilisateur d'un appareil doit avoir un contrôle total sur ce qu'il fait.
La sécurité par l'obscurité ne fonctionne pas, mais DRM n'est pas exactement "sécurité"
La sécurité par l'obscurité des algorithmes est généralement faible. La sécurité par secret des informations est le seul moyen de faire de la cryptographie, de la signature, etc. DRM ne nécessite pas d'obscurité des algorithmes (c'est pourquoi OMA DRM est un norme publiée, et comment se fait-il que la source d'une implémentation puisse être publiée et librement utilisable), mais elle nécessite que l'appareil du lecteur ait accès à des informations (une sorte de clé) que l'utilisateur de l'appareil n'a pas et qui ne le sont pas partie de l'algorithme/source.
Normalement, la sécurité protège le propriétaire/utilisateur d'un appareil contre un modèle de menace d'attaquants externes. Dans le modèle de menace DRM, le propriétaire/utilisateur de l'appareil est l'attaquant et le titulaire des droits est défendu. Si l'utilisateur de l'appareil en a le contrôle total, il est clair qu'en principe, c'est la fin du jeu.
En pratique, cela peut ne pas être aussi immédiat, mais dans le cas de l'open source, autoriser les gens à écrire leurs propres clients DRM qui les empêchent de copier vos données protégées par des droits leur demanderait d'être incroyablement honnête.
Les utilisateurs peuvent parfois être persuadés d'être respectueux des lois, auquel cas les DRM jouent le rôle de leur rappeler que s'ils sautent à travers des cerceaux pour contourner les restrictions, ils peuvent alors enfreindre la loi.
Le DRM open-source est pratiquement impossible.
Le but du DRM est d'empêcher un utilisateur de décrypter certaines données, tout en lui permettant en même temps de le faire dans certaines circonstances. Le cadre théorique du chiffrement rend cela absurde - comment l'utilisateur ne peut-il avoir la clé pour déchiffrer certaines données que s'il les utilise à des fins approuvées?
La solution adoptée par les systèmes DRM existants est d'aller à des longueurs ridicules pour cacher la clé - un exemple parfait de sécurité par obscurité - mais si le code source est disponible, il est trivial de simplement modifier le code pour remettre la clé à l'utilisateur. À ce stade, peu importe la qualité de votre cryptage, l'utilisateur a tout ce dont il a besoin pour le casser.
Une solution à tout cela consiste à utiliser le Trusted Platform Module sur certaines machines pour vérifier l'image binaire de tous les logiciels susceptibles d'accéder à la clé et s'assurer que la clé elle-même est inaccessible (chiffrée par une clé). dérivée d'une valeur secrète gravée dans le matériel). Cependant, je ne sais pas à quel point les TPM sont courants, et en outre, cela va très bien à l'encontre du point de l'open source du logiciel en premier lieu, car vous ne seriez pas en mesure de le modifier de quelque manière que ce soit sans perdre l'accès aux clés DRM.
Enfin, sur une note plus pratique, le DRM semble être de toute façon en train de disparaître - par exemple, iTunes s'est complètement débarrassé du DRM, et l'industrie du film semble également évoluer dans cette direction ...
Pour une solution DRM open source, il y aura probablement une fissure open source.
De nombreuses solutions DRM fonctionnent en fait sur la base du principe de "sécurité par obscurité". Ce qui signifie que certains d'entre eux ne sont pas encore cassés car leurs modèles sont gardés secrets. Même cela n'empêche pas un système DRM majeur de se casser.
Le DRM est rompu car il repose sur le principe de la "sécurité par obscurité".
Il existe d'autres solutions comme le filigrane.
Lorsque vous vendez quelque chose à un client, vous le filigranez avec le nom du client. Si vous trouvez ce tatouage sur le réseau de partage, vous saurez où se trouve la fuite. Si le client sait qu'il y a un filigrane (je pense qu'il est plus honnête de l'avertir), il ne partagera probablement pas.
Je suis généralement anti-DRM. Cependant, j'ai vu une implémentation de DRM que je pouvais prendre en charge, et elle a utilisé les informations de carte de crédit de l'utilisateur comme clé de déchiffrement. Bien qu'il ne soit pas infaillible, il présente au moins l'avantage d'utiliser les informations que l'utilisateur VEUT garder confidentielles. (Au moins en théorie.) Il était toujours portable entre mes propres appareils. Cependant, avec une telle clé visible, plus un lecteur open source, il est possible qu'un utilisateur puisse stocker et copier les données déchiffrées, rendant le DRM théorique.
Cela vaut la peine de mentionner que cela dépend du contenu que vous souhaitez protéger. Si vous souhaitez protéger le contenu que vous possédez vous-même et les dommages si les fuites de contenu ne sont pas dévastatrices, vous pouvez par exemple consulter l'Open IPMP mentionné précédemment. Le projet Suns DReaM est toujours disponible en ligne, il convient toutefois de noter que le projet est fermé en raison de l'inactivité. Un problème survient lorsque vous souhaitez protéger un contenu dont vous n'êtes pas propriétaire. Il est très possible que les propriétaires de contenu ne permettent pas à leur contenu d'être protégé par une solution de DRM open source. Les propriétaires de contenu ont tendance à opter pour des solutions propriétaires comme Microsoft WMDRM/PlayReady, Marlin ou Helix. Donc, si votre framework sera utilisé pour vendre par exemple du contenu hollywoodien, je ne recommanderais pas de mettre du temps dans une solution DRM open source.