Page 1 sur 21, 2 SuivantOpenIPMP, le DRM en mode libre

[antistress]

Un système DRM (gestion numérique des droits sur une oeuvre) libre est possible. La preuve avec la disponibilité de la version 2 d’OpenIPMP, un logiciel DRM interopérable.

Contrairement aux solutions DRM propriétaires, la conception DRM interopérable de OpenIPMP adhère à une variété de normes ouvertes, comme la norme OMA (Open Mobile Alliance) disponible sur les services de téléchargement mobile de musique - en forte progression depuis l’avènement de la 3G -. La solution a été conçue pour être intégrée à n’importe quel système de gestion basé A/V MPEG-4 ou MPEG-2.

Autre avantage de la solution : elle peut être portée facilement sur n’importe quelle plateforme (y compris Windows, Mac, Linux et les plateformes intégrées). Le projet est hébergé sur SourceForge. Il comprend un serveur J2EE pour la gestion des droits et l’octroi de licences, ainsi que des SDK clients pour l’intégration avec les encodeurs et décodeurs MPEG. Ces décodeurs sont en réalité les lecteurs que nous utilisons, "fixes" ou portables.

Selon ses développeurs, cette nouvelle version d’OpenIPMP inclut également un travail de fond sur l’application : interface d’intégration plus lisible avec une gestion de clé "embrochable", une interface de système pleinement cryptographiée ainsi qu’un protocole client-serveur mis à niveau qui utilise désormais les services web (SOAP). Il comprend aussi les fichiers projet VisualStudio v6 et v7 (pour SDK clients), les fichiers projet Eclipse (pour serveur), ainsi que les fichiers makefile linux.

Reste à espérer que fleuriront bientôt des services de téléchargement basés sur cette norme qui mettrait - enfin ! - tout le monde d’accord. Quelques greffons, accords commerciaux et autres mises à jour des logiciels de nos baladeurs numériques seront nécessaires avant cela.

- www.mutablemedia.com

http://www.toolinux.com/news/logiciels/ ... r7903.html

[jobherzt]

ok, mais comment ca marche, concretement ? en quoi c'est "libre" ? (je n'agresse personne, la question m'interresse )

il me semblait que le probleme de compatibilité avec les logiciels libres tenait au fonctionnement meme d'un DRM ( clé cachée dans le code. )

[antistress]

je me pose la même question : J2EE c'est du libre ?

Sinon on peut en théorie concevoir un DRM de la même façon qu'openPGP si j'ai bien compris (je suis pas expert)

[jobherzt]

ben non, openPGP ca sert a comuniquer avec quelqu'un, donc tu cree ta propre clé, ton correspondant aussi, et il n'y a pas de probleme de compatibilité avec des logiciels proprio.

pour le DRM, je ne crois pas que le debat soit technique !! je ne sais toujours pas comment fonctionne en pratique un DRM ( j'aimerais bien), mais peu importe :

a un moment ou a un autre, le logiciel sera capable de lire le contenu du fichier ( il faut bien, sinon pas de son qui sort).. et si c'est un LL, alors on pourra le modifier pour qu'il ecrive ce son sur le disque.

[dupont54]

ben non, openPGP ca sert a comuniquer avec quelqu'un, donc tu cree ta propre clé, ton correspondant aussi, et il n'y a pas de probleme de compatibilité avec des logiciels proprio.

pour le DRM, je ne crois pas que le debat soit technique !! je ne sais toujours pas comment fonctionne en pratique un DRM ( j'aimerais bien), mais peu importe :

a un moment ou a un autre, le logiciel sera capable de lire le contenu du fichier ( il faut bien, sinon pas de son qui sort).. et si c'est un LL, alors on pourra le modifier pour qu'il ecrive ce son sur le disque.

Tout d'accord pareil avec le Monsieur.

PGP, et plus généralement toute la crypto, ont pour objectif d'apporter la réponse à la question suivante : comment Alice peut transmettre à Bob un message via un canal peu sûr, sans qu'Oscar ne puisse le lire ou le modifier.
Or avec les DRM, Bob=Oscar, autrement dit, le destinataire est aussi l'attaquant. Vous pouvez mettre autant de cryptage que vous voulez, ça ne peut PAS marcher, que ce soit libre ou pas.
Le flux audio-vidéo est forcément en clair quelque part. A moins de partir sur des solutions type Trusted-Computing/HDCP, où le flux est crypté de bout en bout. Là, un OS et un lecteur open-source pourrait effectivement faire du DRM sûr. Et encore, la clé finale, certes plus difficile d'accès car dans du hardware, est quand même entre les mains de l'attaquant. De plus, nos yeux et nos oreilles n'étant pas encore HDCP-ready, le "trou analagique" existera toujours...

De toute façon, les DRM ne servent pas à lutter contre le P2P ou le piratage à grand échelle : il n'y a besoin que d'un master déplombé, et c'est reparti comme si de rien n'était.
Ils servent à lutter contre la copie privée : rendre la chose suffisamment compliqué et obscur pour que M Toutlemonde préfère acheter l'album une 2° fois sur iTunes plutôt de ripper son propre CD... ou peut-être, dégouté, préfera-t-il prendre directement la version à haute valeur ajoutée : interopérable, pérenne, mais pirate... A ce titre, ils sont efficaces.

[mmu_man]

Ca existe déjà les DRM libres... enfin en théorie. Y a le truc de Sun (DReaM).

Perso, j'attends toujours une preuve formelle (=mathématique) que c'est possible entièrement en Libre, et sans repousser le problème dans un matériel pour cacher l'algo de cryptage.

De toutes façons ça reste attentatoire à la vie privée et aux libertés individuelles.

[dupont54]

Perso, j'attends toujours une preuve formelle (=mathématique) que c'est possible entièrement en Libre, et sans repousser le problème dans un matériel pour cacher l'algo de cryptage.

Je pense avoir enfin compris comment ils pourraient faire.

D'après la FAQ DReaM :

Q: If a hacker has the source code and architecture details for your DRM solution, won't it be easily compromised?
A: No. A DRM system has multiple levels of security, based on multiple layers of trust. The key to maintaining security within a DRM system is the ability to certify conformant components in the trust chain and be able to quarantine broken elements when detected, as well as refresh the various security components ***spam*** time. No DRM system is perfect; however, with open systems, the opportunity to evaluate and improve protection mechanisms is much greater.
Consider the security that the open source SSL implementations allow. Knowing how a system functions does not help hack the individual ciphers. The root of this question is about the conformance provisions required to ensure that trusted players don't leak content. In order to avoid that problem, the players will need to undergo certification and compliance testing to meet the security requirements that have been specified.

En gros, le truc est de devoir faire "certifier" chaque composant par une autorité indépendante, qui pourrait alors délivrer des clés à ces composants. Et si le composant devient un méchant pirate communiste, sa clé est révoquée -> il cesse de fonctionner, comme dans HDCP.
Ensuite, on peut crypter le contenu en fonction de l'empreinte (et donc de la clé) du lecteur pour être sûr que seul lui peut le lire. On pourrait même certifier des drivers pour éviter une récupération du flux à ce niveau là.
Bref, Linux se met au Trusted Computing.

Le véritable défi, humain et politique, consiste alors à faire une organisation de certification "libre"... En gros, ça reviendrait à nationaliser le consortium derrière CSS ou le HDCP. Mais alors qui va financer, y aura-t-il des délais raisonnables, etc... ?

Une bonne analyse ici: http://blogs.zdnet.com/BTL/?p=2267

[jobherzt]

Ensuite, on peut crypter le contenu en fonction de l'empreinte (et donc de la clé) du lecteur pour être sûr que seul lui peut le lire.

oui, mais si le logiciel peut le lire et est libre (donc modifiable) il peut aussi ecrire sur le disque, graver un CD...

[dupont54]

oui, mais si le logiciel peut le lire et est libre (donc modifiable) il peut aussi ecrire sur le disque, graver un CD...

D'une part, changer le logiciel, ça changerait l'empreinte, donc la clé du logiciel pourrait ne plus être compatible. Bon, j'ai du mal à voir en pratique comment mettre ce genre de mécanisme en action de manière sûre, mais je pense qu'il y a des idées de ce côté-là.

edit: d'ailleurs je viens de voir ce commentaire à l'article que j'ai précédemment cité.

Now comes the hard part. Something has to test the signature on the content and and the signature on the reader binary, and then run the certificate verification. This is the part that has to be really secure. To my knowledge, it has to be done in secure hardware (there is not such thing as secure software). If you cannot do this in secure hardware you cannot have secure DRM. And DRM that is not secure is just a hassle for the user.

Bref, défendre les DRM open-source, c'est aussi défendre le Trusted Computing, car c'est, semble-t-il, la seule manière de le rendre sûr...


D'autre part, si une telle modification circule, la clé peut-être révoquée. Mais là ça me paraît une impasse, car des modifs, il y en aura, donc au final, toutes les clés d'appli open-source se verraient révoquées...

[jobherzt]

oui, mais avec cette histoire de clé, cela suppose qu'on revient a un systeme de logiciel autorisé !! cad que tu ne peux plus modifier le logiciel, ni meme le recompiler sur ta machine avec qq optimisations, sans perdre la capacité de lire les fichiers protégés..

ca reste quand meme assez eloigné du libre.