Bonjour je voudrais savoir comment est-il possible de garantir qu'un
programme s'executant correspond bien à un certain code source.
Un exemple simple ...
Sous windows, media player peut évaluer des licences associées à de la
musique ou de la vidéo (wma, wmv) en mode non connecté. Imaginons qu'un
jour le code de media player soit open source (imaginons j'ai dit :-) ).
N'importe qui pourrait modifier le programme afin de contourner la
vérification des droits. Ma nouvelle licence exprimera que l'utilisateur
a bien le droit à condition que l'évaluation des droits à été faite à
partir d'un certain code source non modifié.
Quand j'en parle, j'ai l'impression que c'est le probème de l'oeuf et la
poule ...
Je pense que c'est un problème recurent dans la gestion des droits
numérique (DRM). Les solutions actuelles (microsoft, apple, real ...)
reposent sur l'hypothèse que leur code est fermé. Comment transposer ce
problème dans un environnement open-source.
Sous windows, media player peut évaluer des licences associées à de la musique ou de la vidéo (wma, wmv) en mode non connecté. Imaginons qu'un jour le code de media player soit open source (imaginons j'ai dit :-) ). N'importe qui pourrait modifier le programme afin de contourner la vérification des droits. Ma nouvelle licence exprimera que l'utilisateur a bien le droit à condition que l'évaluation des droits à été faite à partir d'un certain code source non modifié.
Quand j'en parle, j'ai l'impression que c'est le probème de l'oeuf et la poule ...
Je pense que c'est un problème recurent dans la gestion des droits numérique (DRM). Les solutions actuelles (microsoft, apple, real ...) reposent sur l'hypothèse que leur code est fermé. Comment transposer ce problème dans un environnement open-source.
J'ai envie de dire que c'est impossible.
Le fichier qui contient la musique est quelque chose de complètement statique, ça ne bouge pas. Mathématiquement, c'est un nombre entier, très grand certes, mais un nombre et rien de plus.
La question est de savoir : comment transformer ce nombre en un autre nombre qui code la musique ou l'image ou... sous une forme directement exploitable par le matériel ? Il y a une formule, plus ou moins complexe, qui fait ce calcul. Informatiquement, c'est le coeur du programme de décodage, le codec.
La question est : connaît-on cette formule ?
- Si oui, on peut l'appliquer, il n'y a rien qui puisse nous en empêcher, pas plus qu'on puisse nous empêcher de calculer 2×x+1.
- Si non, alors on ne peut pas lire les données, à moins que...
- Si non, on peut demander à un tiers qui connaît la formule de faire le décodage pour nous. C'est comme ça que marche le DRM en closed-source : le tiers qui connaît la formule est l'exécutable sur notre disque, mais un exécutable opaque, et qui fait les vérifications que son auteur veut.
À noter que le DRM peut fonctionner en ligne sur le troisième modèle, le tiers-qui-connaît-la-formule étant un serveur distant (en fait, il connaît la partie difficile de la formule, probablement la clef asymétrique secrète qui permet d'obtenir la clef de session avec laquelle le fichier est chiffré, ou quelque chose comme ça), mais même comme ça, si le client est contrôlable par son utilisateur, il peut parfaitement être modifié pour sauvegarder les données déchiffrées, ou le nécessaire pour les déchiffrer, et pouvoir ensuite relire les données sans restrictions.
D'ailleurs, ce n'est pas tant une question de programme fermé ou pas. Des gens qui jouent du désassembleur et font sauter les protections de logiciels, il y en a depuis des années.
Bref, le modèle du DRM est fondamentalement foireux.
D'une manière générale, il n'est pas possible pour une donnée, ou pour un interlocuteur réseau, de vérifier ce que son exploiteur/interlocuteur _est_, uniquement ce qu'il _fait_/_dit_. Sauf bien sûr si quelqu'un d'un niveau au dessus, OS ou matériel, vient s'en mêler...
Soon wrote in message <cl7scg$3vl$1@matell.enst-bretagne.fr>:
Sous windows, media player peut évaluer des licences associées à de la
musique ou de la vidéo (wma, wmv) en mode non connecté. Imaginons qu'un
jour le code de media player soit open source (imaginons j'ai dit :-) ).
N'importe qui pourrait modifier le programme afin de contourner la
vérification des droits. Ma nouvelle licence exprimera que l'utilisateur
a bien le droit à condition que l'évaluation des droits à été faite à
partir d'un certain code source non modifié.
Quand j'en parle, j'ai l'impression que c'est le probème de l'oeuf et la
poule ...
Je pense que c'est un problème recurent dans la gestion des droits
numérique (DRM). Les solutions actuelles (microsoft, apple, real ...)
reposent sur l'hypothèse que leur code est fermé. Comment transposer ce
problème dans un environnement open-source.
J'ai envie de dire que c'est impossible.
Le fichier qui contient la musique est quelque chose de complètement
statique, ça ne bouge pas. Mathématiquement, c'est un nombre entier, très
grand certes, mais un nombre et rien de plus.
La question est de savoir : comment transformer ce nombre en un autre nombre
qui code la musique ou l'image ou... sous une forme directement exploitable
par le matériel ? Il y a une formule, plus ou moins complexe, qui fait ce
calcul. Informatiquement, c'est le coeur du programme de décodage, le codec.
La question est : connaît-on cette formule ?
- Si oui, on peut l'appliquer, il n'y a rien qui puisse nous en empêcher,
pas plus qu'on puisse nous empêcher de calculer 2×x+1.
- Si non, alors on ne peut pas lire les données, à moins que...
- Si non, on peut demander à un tiers qui connaît la formule de faire le
décodage pour nous. C'est comme ça que marche le DRM en closed-source : le
tiers qui connaît la formule est l'exécutable sur notre disque, mais un
exécutable opaque, et qui fait les vérifications que son auteur veut.
À noter que le DRM peut fonctionner en ligne sur le troisième modèle, le
tiers-qui-connaît-la-formule étant un serveur distant (en fait, il connaît
la partie difficile de la formule, probablement la clef asymétrique secrète
qui permet d'obtenir la clef de session avec laquelle le fichier est
chiffré, ou quelque chose comme ça), mais même comme ça, si le client est
contrôlable par son utilisateur, il peut parfaitement être modifié pour
sauvegarder les données déchiffrées, ou le nécessaire pour les déchiffrer,
et pouvoir ensuite relire les données sans restrictions.
D'ailleurs, ce n'est pas tant une question de programme fermé ou pas. Des
gens qui jouent du désassembleur et font sauter les protections de
logiciels, il y en a depuis des années.
Bref, le modèle du DRM est fondamentalement foireux.
D'une manière générale, il n'est pas possible pour une donnée, ou pour un
interlocuteur réseau, de vérifier ce que son exploiteur/interlocuteur _est_,
uniquement ce qu'il _fait_/_dit_. Sauf bien sûr si quelqu'un d'un niveau au
dessus, OS ou matériel, vient s'en mêler...
Sous windows, media player peut évaluer des licences associées à de la musique ou de la vidéo (wma, wmv) en mode non connecté. Imaginons qu'un jour le code de media player soit open source (imaginons j'ai dit :-) ). N'importe qui pourrait modifier le programme afin de contourner la vérification des droits. Ma nouvelle licence exprimera que l'utilisateur a bien le droit à condition que l'évaluation des droits à été faite à partir d'un certain code source non modifié.
Quand j'en parle, j'ai l'impression que c'est le probème de l'oeuf et la poule ...
Je pense que c'est un problème recurent dans la gestion des droits numérique (DRM). Les solutions actuelles (microsoft, apple, real ...) reposent sur l'hypothèse que leur code est fermé. Comment transposer ce problème dans un environnement open-source.
J'ai envie de dire que c'est impossible.
Le fichier qui contient la musique est quelque chose de complètement statique, ça ne bouge pas. Mathématiquement, c'est un nombre entier, très grand certes, mais un nombre et rien de plus.
La question est de savoir : comment transformer ce nombre en un autre nombre qui code la musique ou l'image ou... sous une forme directement exploitable par le matériel ? Il y a une formule, plus ou moins complexe, qui fait ce calcul. Informatiquement, c'est le coeur du programme de décodage, le codec.
La question est : connaît-on cette formule ?
- Si oui, on peut l'appliquer, il n'y a rien qui puisse nous en empêcher, pas plus qu'on puisse nous empêcher de calculer 2×x+1.
- Si non, alors on ne peut pas lire les données, à moins que...
- Si non, on peut demander à un tiers qui connaît la formule de faire le décodage pour nous. C'est comme ça que marche le DRM en closed-source : le tiers qui connaît la formule est l'exécutable sur notre disque, mais un exécutable opaque, et qui fait les vérifications que son auteur veut.
À noter que le DRM peut fonctionner en ligne sur le troisième modèle, le tiers-qui-connaît-la-formule étant un serveur distant (en fait, il connaît la partie difficile de la formule, probablement la clef asymétrique secrète qui permet d'obtenir la clef de session avec laquelle le fichier est chiffré, ou quelque chose comme ça), mais même comme ça, si le client est contrôlable par son utilisateur, il peut parfaitement être modifié pour sauvegarder les données déchiffrées, ou le nécessaire pour les déchiffrer, et pouvoir ensuite relire les données sans restrictions.
D'ailleurs, ce n'est pas tant une question de programme fermé ou pas. Des gens qui jouent du désassembleur et font sauter les protections de logiciels, il y en a depuis des années.
Bref, le modèle du DRM est fondamentalement foireux.
D'une manière générale, il n'est pas possible pour une donnée, ou pour un interlocuteur réseau, de vérifier ce que son exploiteur/interlocuteur _est_, uniquement ce qu'il _fait_/_dit_. Sauf bien sûr si quelqu'un d'un niveau au dessus, OS ou matériel, vient s'en mêler...
Nicob
On Thu, 21 Oct 2004 09:54:20 +0000, Soon wrote:
Bonjour je voudrais savoir comment est-il possible de garantir qu'un programme s'executant correspond bien à un certain code source.
Impossible de grantir cela.
A ce sujet, lire le papier "Reflections on Trusting Trust" par Ken Thompson :
http://www.acm.org/classics/sep95/
Un grand classique ...
Nicob
On Thu, 21 Oct 2004 09:54:20 +0000, Soon wrote:
Bonjour je voudrais savoir comment est-il possible de garantir qu'un
programme s'executant correspond bien à un certain code source.
Impossible de grantir cela.
A ce sujet, lire le papier "Reflections on Trusting Trust" par Ken
Thompson :
Bonjour je voudrais savoir comment est-il possible de garantir qu'un programme s'executant correspond bien à un certain code source.
Impossible de grantir cela.
A ce sujet, lire le papier "Reflections on Trusting Trust" par Ken Thompson :
http://www.acm.org/classics/sep95/
Un grand classique ...
Nicob
Fabien LE LEZ
On 21 Oct 2004 12:37:57 GMT, Nicolas George <nicolas$:
mais même comme ça, si le client est contrôlable par son utilisateur, il peut parfaitement être modifié pour sauvegarder les données déchiffrées, ou le nécessaire pour les déchiffrer, et pouvoir ensuite relire les données sans restrictions.
Euh... Y'a un truc que je ne comprends pas dans ta démonstration. A partir du moment où les données sont déchiffrées une fois, à quoi ça sert de bricoler pour les déchiffrer une deuxième fois ? Il suffit de les enregistrer la première fois...
-- ;-)
On 21 Oct 2004 12:37:57 GMT, Nicolas George
<nicolas$george@salle-s.org>:
mais même comme ça, si le client est
contrôlable par son utilisateur, il peut parfaitement être modifié pour
sauvegarder les données déchiffrées, ou le nécessaire pour les déchiffrer,
et pouvoir ensuite relire les données sans restrictions.
Euh... Y'a un truc que je ne comprends pas dans ta démonstration. A
partir du moment où les données sont déchiffrées une fois, à quoi ça
sert de bricoler pour les déchiffrer une deuxième fois ? Il suffit de
les enregistrer la première fois...
On 21 Oct 2004 12:37:57 GMT, Nicolas George <nicolas$:
mais même comme ça, si le client est contrôlable par son utilisateur, il peut parfaitement être modifié pour sauvegarder les données déchiffrées, ou le nécessaire pour les déchiffrer, et pouvoir ensuite relire les données sans restrictions.
Euh... Y'a un truc que je ne comprends pas dans ta démonstration. A partir du moment où les données sont déchiffrées une fois, à quoi ça sert de bricoler pour les déchiffrer une deuxième fois ? Il suffit de les enregistrer la première fois...
-- ;-)
Nicolas George
Fabien LE LEZ wrote in message :
Euh... Y'a un truc que je ne comprends pas dans ta démonstration. A partir du moment où les données sont déchiffrées une fois, à quoi ça sert de bricoler pour les déchiffrer une deuxième fois ? Il suffit de les enregistrer la première fois...
Oh, ça n'a rien de sorcier : il vaut toujours mieux (dans le cas de codages à partes) éviter les cycles de décompression-recompression, surtout si le codec d'origine est bon, et selon comment est organisé le programme du décodeur, il peut être plus facile de le patcher pour lui faire accepter la clef de déchiffrement par un endroit différent qu'un fichier déjà déchiffré. C'est un détail sordide de mise au point, qui n'a pas grande importance dans le fond.
Il faut quand même voir qu'il y a des lecteurs qui prétendent empêcher d'enregistrer le résultat décodé, par exemple ce crétin d'acrobat reader qui désactive le copier-coller et l'impression. C'est typiquemnt le genre de chose qui ennuie les gens honnêtes, et ne gène en rien les autres.
Fabien LE LEZ wrote in message
<7jcfn012oedivsvgra2o840016toubapah@4ax.com>:
Euh... Y'a un truc que je ne comprends pas dans ta démonstration. A
partir du moment où les données sont déchiffrées une fois, à quoi ça
sert de bricoler pour les déchiffrer une deuxième fois ? Il suffit de
les enregistrer la première fois...
Oh, ça n'a rien de sorcier : il vaut toujours mieux (dans le cas de codages
à partes) éviter les cycles de décompression-recompression, surtout si le
codec d'origine est bon, et selon comment est organisé le programme du
décodeur, il peut être plus facile de le patcher pour lui faire accepter la
clef de déchiffrement par un endroit différent qu'un fichier déjà déchiffré.
C'est un détail sordide de mise au point, qui n'a pas grande importance dans
le fond.
Il faut quand même voir qu'il y a des lecteurs qui prétendent empêcher
d'enregistrer le résultat décodé, par exemple ce crétin d'acrobat reader qui
désactive le copier-coller et l'impression. C'est typiquemnt le genre de
chose qui ennuie les gens honnêtes, et ne gène en rien les autres.
Euh... Y'a un truc que je ne comprends pas dans ta démonstration. A partir du moment où les données sont déchiffrées une fois, à quoi ça sert de bricoler pour les déchiffrer une deuxième fois ? Il suffit de les enregistrer la première fois...
Oh, ça n'a rien de sorcier : il vaut toujours mieux (dans le cas de codages à partes) éviter les cycles de décompression-recompression, surtout si le codec d'origine est bon, et selon comment est organisé le programme du décodeur, il peut être plus facile de le patcher pour lui faire accepter la clef de déchiffrement par un endroit différent qu'un fichier déjà déchiffré. C'est un détail sordide de mise au point, qui n'a pas grande importance dans le fond.
Il faut quand même voir qu'il y a des lecteurs qui prétendent empêcher d'enregistrer le résultat décodé, par exemple ce crétin d'acrobat reader qui désactive le copier-coller et l'impression. C'est typiquemnt le genre de chose qui ennuie les gens honnêtes, et ne gène en rien les autres.
Beretta Vexee
Nicolas George <nicolas$ ecrivait dans news:cl84rv$n6e$:
- Si non, on peut demander à un tiers qui connaît la formule de faire le décodage pour nous. C'est comme ça que marche le DRM en closed-source : le tiers qui connaît la formule est l'exécutable sur notre disque, mais un exécutable opaque, et qui fait les vérifications que son auteur veut.
À noter que le DRM peut fonctionner en ligne sur le troisième modèle, le tiers-qui-connaît-la-formule étant un serveur distant (en fait, il connaît la partie difficile de la formule, probablement la clef asymétrique secrète qui permet d'obtenir la clef de session avec laquelle le fichier est chiffré, ou quelque chose comme ça), mais même comme ça, si le client est contrôlable par son utilisateur, il peut parfaitement être modifié pour sauvegarder les données déchiffrées, ou le nécessaire pour les déchiffrer, et pouvoir ensuite relire les données sans restrictions.
En effet la prochaine étape logique du DRM une fois que celui-ci sera un minimum standardisé sera de faire passer le tier de confiance du programme vers une boite noir plus resistante que les soft, comme un module integré au processeur ou un puce annexe destiné a la decompression et a la gestion autonome des licence.
C'est la que l'on rejoin la fameuse informatique de confiance de chers MS, partir d'une infime boite noir bien fortifié au coeur du processeur pour etandre l'obscurité au systeme et a certains executable.
D'ailleurs, ce n'est pas tant une question de programme fermé ou pas. Des gens qui jouent du désassembleur et font sauter les protections de logiciels, il y en a depuis des années.
Les problémes arriveront quand il faurdra reverser ou hacker des processeurs, ce ne sera pas impossible mais beaucoup plus long et dur.
Bref, le modèle du DRM est fondamentalement foireux.
D'un point de vue theorique totalement, le client se retrouve avec le contenue crypté, l'algo et la clée de décryptage dans les mains. D'un point de vue pratique il est tous a fait envisagable de faire des DRM éfficasse ou qui impose des pertes du a des convertions/recompressions et c'est bien la le probléme.
D'une manière générale, il n'est pas possible pour une donnée, ou pour un interlocuteur réseau, de vérifier ce que son exploiteur/interlocuteur _est_, uniquement ce qu'il _fait_/_dit_. Sauf bien sûr si quelqu'un d'un niveau au dessus, OS ou matériel, vient s'en mêler...
A mon avis il ne faut pas voir les DRM comme des protections absolue, je pence que même les créateur de DRM ne les voient pas comme cela, mais plustot comme des anti-vol pour vélo, ils ne rendent pas le vélo involable loin de la mais ils suffisent souvant a decourager les voleurs ou au pir a les ralentir.
-- Les fautes d'orthographes sus-citées sont déposées auprès de leurs propriétaires respectifs. Aucune responsabilité n'est engagé sur la lisibilité du message ou les éventuelles dommages qu'il peut engendrer. Beretta Vexée [utilisez l'addresse Reply-to, SVP]
Nicolas George <nicolas$george@salle-s.org> ecrivait dans
news:cl84rv$n6e$1@biggoron.nerim.net:
- Si non, on peut demander à un tiers qui connaît la formule de faire
le
décodage pour nous. C'est comme ça que marche le DRM en
closed-source : le tiers qui connaît la formule est l'exécutable sur
notre disque, mais un exécutable opaque, et qui fait les
vérifications que son auteur veut.
À noter que le DRM peut fonctionner en ligne sur le troisième modèle,
le tiers-qui-connaît-la-formule étant un serveur distant (en fait, il
connaît la partie difficile de la formule, probablement la clef
asymétrique secrète qui permet d'obtenir la clef de session avec
laquelle le fichier est chiffré, ou quelque chose comme ça), mais même
comme ça, si le client est contrôlable par son utilisateur, il peut
parfaitement être modifié pour sauvegarder les données déchiffrées, ou
le nécessaire pour les déchiffrer, et pouvoir ensuite relire les
données sans restrictions.
En effet la prochaine étape logique du DRM une fois que celui-ci sera un
minimum standardisé sera de faire passer le tier de confiance du
programme vers une boite noir plus resistante que les soft, comme un
module integré au processeur ou un puce annexe destiné a la decompression
et a la gestion autonome des licence.
C'est la que l'on rejoin la fameuse informatique de confiance de chers
MS, partir d'une infime boite noir bien fortifié au coeur du processeur
pour etandre l'obscurité au systeme et a certains executable.
D'ailleurs, ce n'est pas tant une question de programme fermé ou pas.
Des gens qui jouent du désassembleur et font sauter les protections de
logiciels, il y en a depuis des années.
Les problémes arriveront quand il faurdra reverser ou hacker des
processeurs, ce ne sera pas impossible mais beaucoup plus long et dur.
Bref, le modèle du DRM est fondamentalement foireux.
D'un point de vue theorique totalement, le client se retrouve avec le
contenue crypté, l'algo et la clée de décryptage dans les mains. D'un
point de vue pratique il est tous a fait envisagable de faire des DRM
éfficasse ou qui impose des pertes du a des convertions/recompressions et
c'est bien la le probléme.
D'une manière générale, il n'est pas possible pour une donnée, ou pour
un interlocuteur réseau, de vérifier ce que son
exploiteur/interlocuteur _est_, uniquement ce qu'il _fait_/_dit_. Sauf
bien sûr si quelqu'un d'un niveau au dessus, OS ou matériel, vient
s'en mêler...
A mon avis il ne faut pas voir les DRM comme des protections absolue, je
pence que même les créateur de DRM ne les voient pas comme cela, mais
plustot comme des anti-vol pour vélo, ils ne rendent pas le vélo
involable loin de la mais ils suffisent souvant a decourager les voleurs
ou au pir a les ralentir.
--
Les fautes d'orthographes sus-citées sont déposées auprès de leurs
propriétaires respectifs. Aucune responsabilité n'est engagé sur
la lisibilité du message ou les éventuelles dommages qu'il peut
engendrer. Beretta Vexée [utilisez l'addresse Reply-to, SVP]
Nicolas George <nicolas$ ecrivait dans news:cl84rv$n6e$:
- Si non, on peut demander à un tiers qui connaît la formule de faire le décodage pour nous. C'est comme ça que marche le DRM en closed-source : le tiers qui connaît la formule est l'exécutable sur notre disque, mais un exécutable opaque, et qui fait les vérifications que son auteur veut.
À noter que le DRM peut fonctionner en ligne sur le troisième modèle, le tiers-qui-connaît-la-formule étant un serveur distant (en fait, il connaît la partie difficile de la formule, probablement la clef asymétrique secrète qui permet d'obtenir la clef de session avec laquelle le fichier est chiffré, ou quelque chose comme ça), mais même comme ça, si le client est contrôlable par son utilisateur, il peut parfaitement être modifié pour sauvegarder les données déchiffrées, ou le nécessaire pour les déchiffrer, et pouvoir ensuite relire les données sans restrictions.
En effet la prochaine étape logique du DRM une fois que celui-ci sera un minimum standardisé sera de faire passer le tier de confiance du programme vers une boite noir plus resistante que les soft, comme un module integré au processeur ou un puce annexe destiné a la decompression et a la gestion autonome des licence.
C'est la que l'on rejoin la fameuse informatique de confiance de chers MS, partir d'une infime boite noir bien fortifié au coeur du processeur pour etandre l'obscurité au systeme et a certains executable.
D'ailleurs, ce n'est pas tant une question de programme fermé ou pas. Des gens qui jouent du désassembleur et font sauter les protections de logiciels, il y en a depuis des années.
Les problémes arriveront quand il faurdra reverser ou hacker des processeurs, ce ne sera pas impossible mais beaucoup plus long et dur.
Bref, le modèle du DRM est fondamentalement foireux.
D'un point de vue theorique totalement, le client se retrouve avec le contenue crypté, l'algo et la clée de décryptage dans les mains. D'un point de vue pratique il est tous a fait envisagable de faire des DRM éfficasse ou qui impose des pertes du a des convertions/recompressions et c'est bien la le probléme.
D'une manière générale, il n'est pas possible pour une donnée, ou pour un interlocuteur réseau, de vérifier ce que son exploiteur/interlocuteur _est_, uniquement ce qu'il _fait_/_dit_. Sauf bien sûr si quelqu'un d'un niveau au dessus, OS ou matériel, vient s'en mêler...
A mon avis il ne faut pas voir les DRM comme des protections absolue, je pence que même les créateur de DRM ne les voient pas comme cela, mais plustot comme des anti-vol pour vélo, ils ne rendent pas le vélo involable loin de la mais ils suffisent souvant a decourager les voleurs ou au pir a les ralentir.
-- Les fautes d'orthographes sus-citées sont déposées auprès de leurs propriétaires respectifs. Aucune responsabilité n'est engagé sur la lisibilité du message ou les éventuelles dommages qu'il peut engendrer. Beretta Vexée [utilisez l'addresse Reply-to, SVP]
Stephane Dupille
A mon avis il ne faut pas voir les DRM comme des protections absolue, je pence que même les créateur de DRM ne les voient pas comme cela, mais plustot comme des anti-vol pour vélo, ils ne rendent pas le vélo involable loin de la mais ils suffisent souvant a decourager les voleurs ou au pir a les ralentir.
Voilà, c'est exactement comme ça qu'il faut appréhender les DRM : laisser les gens honnêtes rester honnêtes. D'autre part, les majors s'en foutent complètement du niveau de sécurité : ils veulent que ce ne soit pas facilement copiable, le reste ils s'en tapent, et de toute façon, ils n'y comprennent rien.
Ensuite, il faut bien comprendre une chose : les systèmes DRM n'ont absolument aucune pression en terme de sécurité. Il est tellement plus facile de chercher un morceau sur Kazaa que de casser la DRM... Le jour où Kazaa n'existera plus, la pression sur les technos DRM sera plus forte. D'ici là... Il y a cependant des gens qui tentent de les casser (d'ailleurs FaitPlay, la techno Apple a été cassée), mais c'est très anecdotique.
Sinon, pour la question initiale, non, il n'est pas possible de développer une techno DRM en open source. Par contre, la norme en elle-même peut être libre (par exemple OMA est plus ou moins libre), mais les implémentations sont forcément fermées.
-- Admirez les photos de notre superbe boutre mahorais. Cliquez ici: -+- PB in <http://www.le-gnu.net> : L'e-mail, kes t'en a à boutre -+-
A mon avis il ne faut pas voir les DRM comme des protections absolue, je
pence que même les créateur de DRM ne les voient pas comme cela, mais
plustot comme des anti-vol pour vélo, ils ne rendent pas le vélo
involable loin de la mais ils suffisent souvant a decourager les voleurs
ou au pir a les ralentir.
Voilà, c'est exactement comme ça qu'il faut appréhender les DRM :
laisser les gens honnêtes rester honnêtes. D'autre part, les majors
s'en foutent complètement du niveau de sécurité : ils veulent que ce
ne soit pas facilement copiable, le reste ils s'en tapent, et de toute
façon, ils n'y comprennent rien.
Ensuite, il faut bien comprendre une chose : les systèmes DRM n'ont
absolument aucune pression en terme de sécurité. Il est tellement plus
facile de chercher un morceau sur Kazaa que de casser la DRM... Le
jour où Kazaa n'existera plus, la pression sur les technos DRM sera
plus forte. D'ici là... Il y a cependant des gens qui tentent de les
casser (d'ailleurs FaitPlay, la techno Apple a été cassée), mais c'est
très anecdotique.
Sinon, pour la question initiale, non, il n'est pas possible de
développer une techno DRM en open source. Par contre, la norme en
elle-même peut être libre (par exemple OMA est plus ou moins libre),
mais les implémentations sont forcément fermées.
--
Admirez les photos de notre superbe boutre mahorais. Cliquez ici:
-+- PB in <http://www.le-gnu.net> : L'e-mail, kes t'en a à boutre -+-
A mon avis il ne faut pas voir les DRM comme des protections absolue, je pence que même les créateur de DRM ne les voient pas comme cela, mais plustot comme des anti-vol pour vélo, ils ne rendent pas le vélo involable loin de la mais ils suffisent souvant a decourager les voleurs ou au pir a les ralentir.
Voilà, c'est exactement comme ça qu'il faut appréhender les DRM : laisser les gens honnêtes rester honnêtes. D'autre part, les majors s'en foutent complètement du niveau de sécurité : ils veulent que ce ne soit pas facilement copiable, le reste ils s'en tapent, et de toute façon, ils n'y comprennent rien.
Ensuite, il faut bien comprendre une chose : les systèmes DRM n'ont absolument aucune pression en terme de sécurité. Il est tellement plus facile de chercher un morceau sur Kazaa que de casser la DRM... Le jour où Kazaa n'existera plus, la pression sur les technos DRM sera plus forte. D'ici là... Il y a cependant des gens qui tentent de les casser (d'ailleurs FaitPlay, la techno Apple a été cassée), mais c'est très anecdotique.
Sinon, pour la question initiale, non, il n'est pas possible de développer une techno DRM en open source. Par contre, la norme en elle-même peut être libre (par exemple OMA est plus ou moins libre), mais les implémentations sont forcément fermées.
-- Admirez les photos de notre superbe boutre mahorais. Cliquez ici: -+- PB in <http://www.le-gnu.net> : L'e-mail, kes t'en a à boutre -+-
Fabien LE LEZ
On 22 Oct 2004 17:07:55 GMT, "Stephane Dupille" <sdupille+:
D'autre part, les majors s'en foutent complètement du niveau de sécurité
La preuve : le "cryptage" sur les DVD...
-- ;-)
On 22 Oct 2004 17:07:55 GMT, "Stephane Dupille"
<sdupille+news@teaser.fr>:
D'autre part, les majors
s'en foutent complètement du niveau de sécurité
On 22 Oct 2004 17:07:55 GMT, "Stephane Dupille" <sdupille+:
D'autre part, les majors s'en foutent complètement du niveau de sécurité
La preuve : le "cryptage" sur les DVD...
-- ;-)
Cedric Blancher
Le Fri, 22 Oct 2004 22:13:11 +0000, Fabien LE LEZ a écrit :
La preuve : le "cryptage" sur les DVD...
Le DECSS n'est une mesure de protection contre la copie. C'est une mesure de protection d'un monopole (i.e. contrôler les gens qui peuvent fournir des lecteurs de DVD), déguisée en mesure de protection contre la copie de manière à faire tomber son détournement sous le coup du DMCA.
Ça n'a jamais empêché quelqu'un de copier un DVD avec un graveur de DVD.
-- Que veut dire respecter la netiquette et oû se trouve l'option follow up to ??? -+- K in GNU : Configurer le fu2 vers la Nétiquette -+-
Le Fri, 22 Oct 2004 22:13:11 +0000, Fabien LE LEZ a écrit :
La preuve : le "cryptage" sur les DVD...
Le DECSS n'est une mesure de protection contre la copie. C'est une mesure
de protection d'un monopole (i.e. contrôler les gens qui peuvent fournir
des lecteurs de DVD), déguisée en mesure de protection contre la copie
de manière à faire tomber son détournement sous le coup du DMCA.
Ça n'a jamais empêché quelqu'un de copier un DVD avec un graveur de DVD.
--
Que veut dire respecter la netiquette et oû se trouve
l'option follow up to ???
-+- K in GNU : Configurer le fu2 vers la Nétiquette -+-
Le Fri, 22 Oct 2004 22:13:11 +0000, Fabien LE LEZ a écrit :
La preuve : le "cryptage" sur les DVD...
Le DECSS n'est une mesure de protection contre la copie. C'est une mesure de protection d'un monopole (i.e. contrôler les gens qui peuvent fournir des lecteurs de DVD), déguisée en mesure de protection contre la copie de manière à faire tomber son détournement sous le coup du DMCA.
Ça n'a jamais empêché quelqu'un de copier un DVD avec un graveur de DVD.
-- Que veut dire respecter la netiquette et oû se trouve l'option follow up to ??? -+- K in GNU : Configurer le fu2 vers la Nétiquette -+-
Fabien LE LEZ
On 23 Oct 2004 09:02:27 GMT, Cedric Blancher :
La preuve : le "cryptage" sur les DVD...
Le DECSS n'est une mesure de protection contre la copie.
C'était sensé être un système de zonage. De plus, s'il avait fonctionné, il aurait également peut-être rendu la recompression en MPEG-4 un peu plus difficile.
-- ;-)
On 23 Oct 2004 09:02:27 GMT, Cedric Blancher
<blancher@cartel-securite.fr>:
La preuve : le "cryptage" sur les DVD...
Le DECSS n'est une mesure de protection contre la copie.
C'était sensé être un système de zonage. De plus, s'il avait
fonctionné, il aurait également peut-être rendu la recompression en
MPEG-4 un peu plus difficile.
Le DECSS n'est une mesure de protection contre la copie.
C'était sensé être un système de zonage. De plus, s'il avait fonctionné, il aurait également peut-être rendu la recompression en MPEG-4 un peu plus difficile.
-- ;-)
Cedric Blancher
Le Sat, 23 Oct 2004 10:10:30 +0000, Fabien LE LEZ a écrit :
C'était sensé être un système de zonage.
La zone est un concept différent du "chiffrement" DeCSS. Il vise à ne pas rendre le DVD lisible sur certains lecteurs, i.e. ceux dont la zone diffère de celle enregistrée sur le CD, même s'ils possèdent les jeux de clés DeCSS qui vont bien. Par exemple, il existe de DVD zonés non chiffrés et des DVD chiffrés non zonés, et c'est aussi pour cela que le dézonage est aussi simple, en tout cas nettement plus simple que si DeCSS et zonage avaient été couplés en attribuant des jeux de clés différents à chaque zone.
De plus, s'il avait fonctionné, il aurait également peut-être rendu la recompression en MPEG-4 un peu plus difficile.
Mais il n'aurait pas empêché la copie du support pour autant.
-- MD> je cherche une femme pour avoir le sex, l'amour et des babies ! AD> Pour les grands-mères et les belle-mères, j'ai des contacts en AD> France. C'est plus cher, mais il y a un service après-vente. -+- in : Guide du Neuneu d'Usenet - Neuneu cherche une famille -+-
Le Sat, 23 Oct 2004 10:10:30 +0000, Fabien LE LEZ a écrit :
C'était sensé être un système de zonage.
La zone est un concept différent du "chiffrement" DeCSS. Il vise à ne
pas rendre le DVD lisible sur certains lecteurs, i.e. ceux dont la zone
diffère de celle enregistrée sur le CD, même s'ils possèdent les jeux
de clés DeCSS qui vont bien.
Par exemple, il existe de DVD zonés non chiffrés et des DVD chiffrés
non zonés, et c'est aussi pour cela que le dézonage est aussi simple, en
tout cas nettement plus simple que si DeCSS et zonage avaient été
couplés en attribuant des jeux de clés différents à chaque zone.
De plus, s'il avait fonctionné, il aurait également peut-être rendu
la recompression en MPEG-4 un peu plus difficile.
Mais il n'aurait pas empêché la copie du support pour autant.
--
MD> je cherche une femme pour avoir le sex, l'amour et des babies !
AD> Pour les grands-mères et les belle-mères, j'ai des contacts en
AD> France. C'est plus cher, mais il y a un service après-vente.
-+- in : Guide du Neuneu d'Usenet - Neuneu cherche une famille -+-
Le Sat, 23 Oct 2004 10:10:30 +0000, Fabien LE LEZ a écrit :
C'était sensé être un système de zonage.
La zone est un concept différent du "chiffrement" DeCSS. Il vise à ne pas rendre le DVD lisible sur certains lecteurs, i.e. ceux dont la zone diffère de celle enregistrée sur le CD, même s'ils possèdent les jeux de clés DeCSS qui vont bien. Par exemple, il existe de DVD zonés non chiffrés et des DVD chiffrés non zonés, et c'est aussi pour cela que le dézonage est aussi simple, en tout cas nettement plus simple que si DeCSS et zonage avaient été couplés en attribuant des jeux de clés différents à chaque zone.
De plus, s'il avait fonctionné, il aurait également peut-être rendu la recompression en MPEG-4 un peu plus difficile.
Mais il n'aurait pas empêché la copie du support pour autant.
-- MD> je cherche une femme pour avoir le sex, l'amour et des babies ! AD> Pour les grands-mères et les belle-mères, j'ai des contacts en AD> France. C'est plus cher, mais il y a un service après-vente. -+- in : Guide du Neuneu d'Usenet - Neuneu cherche une famille -+-
