fnacmusic sur iPod

Il n'y a aucune POC contre les DRM, ne déformez pas mes propos.
J'ai oublié le smiley, effectivement.

Mais ce que je disais reste valable: il n'existe personne capable
d'apporter la moindre preuve de la protection contre la copie grâce à
une DRM, puisque ça n'est à ce jour par envisageable.

Et pourtant, ça marche.

On ne peut que rendre la copie (un petit peu) plus difficile.

Le but de la DRM est que les gens honnêtes restent honnêtes.

S'il n'y a pas de soft pour décoder, comment le décodage se fait
alors ? Par magie ?
Dans le module DVB-CI, comme je le dis ci-dessus.

Et s'il n'y a pas de module DVB ?

Je travaille dans une boite qui fait le soft pour ce genre
d'équipement, et la set-top-box dont je parle est équipée d'un
PowerPC, tourne sous Linux, et la carte ne fait que décoder les ECM
pour sortir un CW.
Un STBxxx ?

Non.

Il n'y a que le Pallas, à ma connaissance, qui aie la puissance pour
décoder à l'aise en soft. Je me trompe (peut-être sur le nom...) ?

Il y a forcément du soft.

Et c'est la même carte à puce (enfin, presque, celle de notre démo
est d'une génération plus récente) que celles qui équipent les
décodeurs canal-sat, TPS et Noos.
Tu ne convaincra jamais TPS et Noos d'adopter ton système puisque eux,

justement, imposent que le flux décrypté ne soit jamais visible du CPU,
ce qui rendrait le piratage un peu trop facile à faire.
Ou alors, tu est très convaincant (ou très riche...)

Le décodage ne peut se faire qu'à deux endroits : soit sur le CPU,
soit dans la carte à puce, car ce sont les seules unités qui soient
capables d'effectuer du calcul (j'inclue dans le CPU le DSP s'il y en
a un).

Quant à TPS, ils utilisent une génération de carte qui s'est
fait trouer depuis plusieurs années, et ne veulent pas pour l'instant
passer sur une génération plus récente, alors leur discours sur la
sécurité, hein ! :))

Sinon, j'aimerai bien que tu m'explique comment faire des calculs
sans CPU ? Un décodeur, c'est aussi con qu'un PC : il a un CPU qui
fait tourner un soft, un peu de RAM, une mémoire de masse pour stocker
les softs et basta.

Au fait, les calculateurs spécialisés (comme les DSP) sont des CPU.
Je crois que c'est sur ce point que nous divergeons.

J'ai fait une erreur de vocabulaire au départ: ce n'est pas dans la carte
à puce, mais dans le module DVB-CI (qui est le réceptacle standard de la
carte à puce en question pour tout ce qui est DVB). Attaquer la carte à
puce en direct est techniquement possible, mais prohibé par tous les
fournisseurs de contrôle d'accès existant (c.a.d diffusant des streams
sur le sat ou le cable aujourd'hui).

Oui, et puis la carte se protège.

Si le décodage se fait dans le CPU, c'est un immense cadeau pour les
pirates, surtout si c'est du flux IP: il suffit qu'une set-top-box
décrypte et elle peut diffuser les clés en temps réel pour les copains.

Si c'est de l'IP, c'est pas du DVB ! Et en IP, on n'a pas de modules
spécialisés pour le traitement des flux (en dehors du DSP).

Sinon, encore faut-il récupérer les clés (ce qui n'est pas aussi
facile que tu semble le dire), et ensuite, la clé est changée toutes
les quelques secondes.

Pour info, on peut trouver sur internet les CW des différents
opérateurs cables et satellites. La faille dont tu parle est justifiée
et utilisée. Mais comme les clés changent souvent, et que les délais
de transmission sur internet ne sont pas garantis, le flux est un
petit peu haché... En pratique, c'est pas top !

C'est justement pour éviter celà les clés de décryptage ne doivent
jamais être visibles. C'est même la moindre des choses...

Ils sont forcément visibles, sinon la boite ne peut pas décoder.

Sinon, ce n'est plus de la protection, c'est de la poudre aux yeux...

Bof, il suffit souvent de se brancher derrière le décodeur ou le
module DVB pour sortir un flux numérique en clair. T'as pas besoin de
te faire chier à récupérer la clé. C'est comme pour contourner les
DRM, il vaut mieux graver.

--
Monsieur gagnerait en credibilite en etayant ses accusations;
Tel quel, c'est minable. Bah, yaka attendre - on verra bien
a quel gaz est gonflee cette baudruche.
-+-TC in : <http://www.le-gnu.net> - Le neuneu se déballonne -+-

On Fri, 24 Sep 2004 10:25:44 +0200, Stephane Dupille wrote:

Il n'y a aucune POC contre les DRM, ne déformez pas mes propos.
J'ai oublié le smiley, effectivement.

Mais ce que je disais reste valable: il n'existe personne capable
d'apporter la moindre preuve de la protection contre la copie grâce à
une DRM, puisque ça n'est à ce jour par envisageable.

Et pourtant, ça marche.

Sur les prospectus publicitaires, oui. Du moins, pour ce qui se fait
aujourd'hui.

On ne peut que rendre la copie (un petit peu) plus difficile.

Le but de la DRM est que les gens honnêtes restent honnêtes.

S'il n'y a pas de soft pour décoder, comment le décodage se fait
alors ? Par magie ?
Dans le module DVB-CI, comme je le dis ci-dessus.

Et s'il n'y a pas de module DVB ?

S'il n'y a pas de module DVB-CI, il faut bien en effet le faire en soft.

Je travaille dans une boite qui fait le soft pour ce genre
d'équipement, et la set-top-box dont je parle est équipée d'un
PowerPC, tourne sous Linux, et la carte ne fait que décoder les ECM
pour sortir un CW.
Un STBxxx ?

Non.

C'est vrai que pour du MPEG 4, ce n'est pas le hard le plus adapté, ou
plutôt il y a pas mal de silicium qui ne servirait à rien... Je n'y ai
pas pensé en écrivant celà...

Il n'y a que le Pallas, à ma connaissance, qui aie la puissance pour
décoder à l'aise en soft. Je me trompe (peut-être sur le nom...) ?

Il y a forcément du soft.

Les STBxxx décodent le MPEG2 en hard. Il y a du soft pour commander le
tuner et paramétrer le décodage, mais pas pour le décodage lui même.
Si c'est du MPEG 4, il faut le faire en soft et bien optimiser: le plus
rapide plafonne, je crois, à 262 Mhz.

Et c'est la même carte à puce (enfin, presque, celle de notre démo
est d'une génération plus récente) que celles qui équipent les
décodeurs canal-sat, TPS et Noos.
Tu ne convaincra jamais TPS et Noos d'adopter ton système puisque eux,

justement, imposent que le flux décrypté ne soit jamais visible du CPU,
ce qui rendrait le piratage un peu trop facile à faire.
Ou alors, tu est très convaincant (ou très riche...)

Le décodage ne peut se faire qu'à deux endroits : soit sur le CPU,
soit dans la carte à puce, car ce sont les seules unités qui soient
capables d'effectuer du calcul (j'inclue dans le CPU le DSP s'il y en
a un).

Le décryptage peut être fait dans le module DVB-CI. C'est même la
seule chose que sache faire un module de ce type...

[...]

Sinon, j'aimerai bien que tu m'explique comment faire des calculs
sans CPU ? Un décodeur, c'est aussi con qu'un PC : il a un CPU qui
fait tourner un soft, un peu de RAM, une mémoire de masse pour stocker
les softs et basta.

Je n'ai pas parlé de faire faire des calculs sans CPU, j'ai parlé
d'utiliser du hard spécialisé et (en principe, je ne sais pas ce que
font les fondeurs en pratique...) sécurisé.

Au fait, les calculateurs spécialisés (comme les DSP) sont des CPU.
Je crois que c'est sur ce point que nous divergeons.

Je suis tout à fait d'accord mais ce que j'appelle le CPU c'est, comme
son nom l'indique, le processeur central de la set-top-box. Il n'est
généralement pas sécurisé, utilise rarement de la RAM interne ou
cryptée, bref, c'est souvent le point le plus faible en terme de
sécurité. D'autant plus qu'il est souvent bien documenté et qu'une
personne motivée arrivera à faire tourner du soft dessus: je l'ai vu
faire.

J'ai fait une erreur de vocabulaire au départ: ce n'est pas dans la carte
à puce, mais dans le module DVB-CI (qui est le réceptacle standard de la
carte à puce en question pour tout ce qui est DVB). Attaquer la carte à
puce en direct est techniquement possible, mais prohibé par tous les
fournisseurs de contrôle d'accès existant (c.a.d diffusant des streams
sur le sat ou le cable aujourd'hui).

Oui, et puis la carte se protège.

Si le décodage se fait dans le CPU, c'est un immense cadeau pour les
pirates, surtout si c'est du flux IP: il suffit qu'une set-top-box
décrypte et elle peut diffuser les clés en temps réel pour les copains.

Si c'est de l'IP, c'est pas du DVB ! Et en IP, on n'a pas de modules
spécialisés pour le traitement des flux (en dehors du DSP).

Ce n'est pas parce que ce n'est pas de l'IP qu'on ne peut pas utiliser du
hard spécialisé (y compris un module de type DVB-CI) et sécurisé pour
décrypter. Le moyen de transport du flux n'a pas de rapport avec la
façon dont il est protégé et décrypté, ce sont deux problèmes
complètements indépendants.

Sinon, encore faut-il récupérer les clés (ce qui n'est pas aussi
facile que tu semble le dire)

C'est assez trivial, pourtant, quand tu sais comment communique une carte
à puce. Sauf si les clées sont elle mêmes cryptées de façon forte
entre la carte à puce et le CPU... Si c'est le cas, il faut les
récupérer en RAM, ce qui est plus dur car il faut "deviner" ou elles
sont...

et ensuite, la clé est changée toutes
les quelques secondes.

Si vous le faites si fréquement, bravo, mais les intervalles de
renouvellement des clés dans des flux réels (je veux dire utilisés en
production aujourd'hui) sont bien plus grand que celà.

[...]

C'est justement pour éviter celà les clés de décryptage ne doivent
jamais être visibles. C'est même la moindre des choses...

Ils sont forcément visibles, sinon la boite ne peut pas décoder.

Les clés peuvent n'être utilisées que dans du hard de façon à ce
qu'elle ne soient jamais visible de l'extérieur de ce hard. Ce n'est pas
une protection absolue: il y a des acharnés qui arrivent à retrouver des
infos au milieu d'un morceau de silicium en fonctionnement, mais ce genre
de techniques demande un peu trop de matériel et de connaissance pour un
p'tit gars qui veut juste regarder un film sans payer...

Sinon, ce n'est plus de la protection, c'est de la poudre aux yeux...

Bof, il suffit souvent de se brancher derrière le décodeur ou le
module DVB pour sortir un flux numérique en clair. T'as pas besoin de
te faire chier à récupérer la clé. C'est comme pour contourner les
DRM, il vaut mieux graver.

Je ne prétends pas que le module dédié soit la panacée, je dis que
c'est déjà mieux que le décryptage soft par le CPU. Il faut quand même
bidouiller du hard pour récupérer le flux entre le module et le
décodeur MPEG (qu'il soit en hard ou en soft...), alors que l'autre
méthode nécessite juste de faire tourner un soft qui pirate les clés ou
le flux, ce qui est bien plus simple.
Mais, je reviens à ce que disais au départ: la seule méthode de DRM
fiable implique le flux soit crypté jusqu'au dernier instant ou, au
moins, ne puisse être récupéré que dans un état très dégradé.
Ceci implique que le décodeur soit dans le périphérique d'affichage
(donc la télé, généralement) et que aucune donnée numérique ne
puisse être visible en clair, y compris sur les bus de la carte mère:
j'ai déjà vu des gens espionner des bus pour essayer de comprendre ce
que faisait un programe... Et bien sur, ça implique que le soft ne puisse
pas non plus être obtenu, y compris en essayant de disséquer un soft de
mise à jour obtenu légalement.
Techniquement, tout ça est faisable, sans grand surcoût, d'ailleurs.
Personne ne l'a encore fait car les diffuseurs se contentent des solutions
existantes et passent leur temps à expliquer aux ayants-droits que leurs
solutions sont fiables et à la pointe de la technique (enfin, c'est, je
pense, la raison).
Si tu met en oeuvre une solution de ce type, alors le
fait que tu décrypte dans du hard sécurisé ou en soft n'a aucune
importance, les deux solutions deviennent équivalentes en terme de
sécurité, puisque on ne peut jamais accéder de quelque manière aux
données. Le choix est alors juste un problème de coût et
d'évolutivité. Je pense que, pour ces critères, la solution soft est de
loin préférable.

Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:

Il y a aussi eu une modification dans iTunes pour qu'il refuse de lire des
AAC qu'il identifiait comme ayant été déprotégés.

Bof, en tout cas, j''ai déplombé les quelques morceaux que j'ai acheté
sur l'iTMS avec Hymn, et je n'ai aucun problèmes avec iTunes pour les
lire ou les synchroniser avec mon iPod.

Bertrand

Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:

On est d'accord que seul celui qui a acheté le morceau peut le décrypter,
mais pouvoir décrypter un morceau que l'on a pas acheté n'aurait de toute
façon aucun intérêt supplémentaire, même pour un pirate.

Oui, étant entendu qu'il faut que le morceau ait de tout façon été
acheté sur l'iTMS, ce qui signifie que l'acheteur en possède
nécessairement la clef.
Les DRM n'ont pas de sens a être envisagés d'une autre manière, i.e. un
morceau protégé récupéré "par hasard". Ce n'est pas l'hypothèse la plus
vraissemblable pour entrer en possession d'un fichier protégé qui a de
toute manière été acheté à un moment ou à un autre.

Bertrand

In article
<1gkq7hi.1744qogkwz78kN%bertrand.bachellerie_no@spam_free.fr>,
bertrand.bachellerie_no@spam_free.fr (Bertrand Bachellerie) wrote:

Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:

Il y a aussi eu une modification dans iTunes pour qu'il refuse de lire des
AAC qu'il identifiait comme ayant été déprotégés.

Bof, en tout cas, j''ai déplombé les quelques morceaux que j'ai acheté
sur l'iTMS avec Hymn, et je n'ai aucun problèmes avec iTunes pour les
lire ou les synchroniser avec mon iPod.

Oui, Hymn a évidemment été modifié en conséquence.

Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>

Il n'y a aucune POC contre les DRM, ne déformez pas mes propos.
J'ai oublié le smiley, effectivement.

Mais ce que je disais reste valable: il n'existe personne capable
d'apporter la moindre preuve de la protection contre la copie grâce à
une DRM, puisque ça n'est à ce jour par envisageable.
Et pourtant, ça marche.

Sur les prospectus publicitaires, oui. Du moins, pour ce qui se fait

aujourd'hui.

Alors citez-moi une source sérieuse qui indique une faille dans les
systèmes DRM (hors ceux d'Apple qui sont troués).

Et s'il n'y a pas de module DVB ?
S'il n'y a pas de module DVB-CI, il faut bien en effet le faire en soft.

Parce que le module DVB ne contient pas de soft peut-être ?

Il y a forcément du soft.
Les STBxxx décodent le MPEG2 en hard. Il y a du soft pour commander le

tuner et paramétrer le décodage, mais pas pour le décodage lui même.

Il y a forcément du soft, même dans une puce. Tout traitement
informatique (sur le modèle de Von Neumann, le seul qui existe à
l'heure actuelle) nécessite une puissance de calcul (un CPU) et du
soft. Ou alors vous avez une set-top-box quantique.

Il existe bien entendu des puces spécialisées, qui embarquent le
soft, mais le soft existe toujours. Une carte à puce embarque du soft.
Un processeur type Intel ou PowerPC intègre bien plus de soft que vous
ne pouvez l'imaginer. Ce n'est pas parce que vous parlez d'une puce
spécialisée qu'elle n'a pas de soft.

Si c'est du MPEG 4, il faut le faire en soft et bien optimiser: le plus
rapide plafonne, je crois, à 262 Mhz.

On peut décoder du MPEG avec ce qu'on veut.

Le décodage ne peut se faire qu'à deux endroits : soit sur le CPU,
soit dans la carte à puce, car ce sont les seules unités qui soient
capables d'effectuer du calcul (j'inclue dans le CPU le DSP s'il y en
a un).
Le décryptage peut être fait dans le module DVB-CI. C'est même la

seule chose que sache faire un module de ce type...

Quand on a un flux DVB, oui, mais ce n'est pas toujours le cas.
Et un module DVB, c'est quoi à part un CPU et du soft embarqué ?

Sinon, j'aimerai bien que tu m'explique comment faire des calculs
sans CPU ? Un décodeur, c'est aussi con qu'un PC : il a un CPU qui
fait tourner un soft, un peu de RAM, une mémoire de masse pour stocker
les softs et basta.
Je n'ai pas parlé de faire faire des calculs sans CPU, j'ai parlé

d'utiliser du hard spécialisé et (en principe, je ne sais pas ce que
font les fondeurs en pratique...) sécurisé.

C'est donc un CPU, CQFD. Que ce soit spécialisé ou pas, c'est un
CPU.

Au fait, les calculateurs spécialisés (comme les DSP) sont des CPU.
Je crois que c'est sur ce point que nous divergeons.
Je suis tout à fait d'accord mais ce que j'appelle le CPU c'est, comme

son nom l'indique, le processeur central de la set-top-box.

D'accord, mais c'est souvent lui qui sert à communiquer avec la
carte à puce, et ainsi transférer les clés.

Il n'est
généralement pas sécurisé, utilise rarement de la RAM interne ou
cryptée, bref, c'est souvent le point le plus faible en terme de
sécurité. D'autant plus qu'il est souvent bien documenté et qu'une
personne motivée arrivera à faire tourner du soft dessus: je l'ai vu
faire.

Oui. Souvent le CPU est un modèle très courant : on a des PowerPC
chez nous.

Ce n'est pas parce que ce n'est pas de l'IP qu'on ne peut pas utiliser du
hard spécialisé (y compris un module de type DVB-CI) et sécurisé pour
décrypter.

Bien entendu, mais maintenant qu'on a des CPU qui sont assez
puissant pour le faire, on ne va pas se géner pour l'utiliser. C'est
beaucoup moins cher comme ç.

Le moyen de transport du flux n'a pas de rapport avec la
façon dont il est protégé et décrypté, ce sont deux problèmes
complètements indépendants.

Bien entendu, mais ce n'est pas ça dont on parlait.

Sinon, encore faut-il récupérer les clés (ce qui n'est pas aussi
facile que tu semble le dire)
C'est assez trivial, pourtant, quand tu sais comment communique une carte

à puce.

Encore faut-il avoir les équipements qui vont bien. Je ne dit pas
que c'est impossible, je dit que ce n'est pas aussi trivial que ça.

Sauf si les clées sont elle mêmes cryptées de façon forte
entre la carte à puce et le CPU... Si c'est le cas, il faut les
récupérer en RAM, ce qui est plus dur car il faut "deviner" ou elles
sont...

Oui.

et ensuite, la clé est changée toutes les quelques secondes.
Si vous le faites si fréquement, bravo, mais les intervalles de

renouvellement des clés dans des flux réels (je veux dire utilisés en
production aujourd'hui) sont bien plus grand que celà.

Toutes les 10 (dix) secondes en production chez les principaux
opérateurs du cable et du satellite. Du moins les flux que la boite
dans laquelle je travaille protège.

Ils sont forcément visibles, sinon la boite ne peut pas décoder.
Les clés peuvent n'être utilisées que dans du hard de façon à ce

qu'elle ne soient jamais visible de l'extérieur de ce hard. Ce n'est pas
une protection absolue: il y a des acharnés qui arrivent à retrouver des
infos au milieu d'un morceau de silicium en fonctionnement, mais ce genre
de techniques demande un peu trop de matériel et de connaissance pour un
p'tit gars qui veut juste regarder un film sans payer...

C'est exactement ce que je voulais dire. Sauf que je dis que le hard
n'a pas besoin d'être aussi spécialisé que vous le dites : en
pratique, ce n'est pas plus sûr d'avoir un truc fermé.

Bof, il suffit souvent de se brancher derrière le décodeur ou le
module DVB pour sortir un flux numérique en clair. T'as pas besoin de
te faire chier à récupérer la clé. C'est comme pour contourner les
DRM, il vaut mieux graver.
Je ne prétends pas que le module dédié soit la panacée, je dis que

c'est déjà mieux que le décryptage soft par le CPU. Il faut quand même
bidouiller du hard pour récupérer le flux entre le module et le
décodeur MPEG (qu'il soit en hard ou en soft...), alors que l'autre
méthode nécessite juste de faire tourner un soft qui pirate les clés ou
le flux, ce qui est bien plus simple.

Ce n'est pas forcément plus simple. Et encore faut-il pouvoir
injecter le soft. Enfin, entendons-nous bien : on peut injecter du
soft, mais le faire sans faire pêter le soft déjà présent est très
compliqué ! Ça revient a faire du reverse-engeniering, et une fois
qu'on l'a fait, on n'a plus besoin d'injecter du code.

C'est pas à la portée du premier venu.

Mais, je reviens à ce que disais au départ: la seule méthode de DRM
fiable implique le flux soit crypté jusqu'au dernier instant ou, au
moins, ne puisse être récupéré que dans un état très dégradé.

Oui.

Ceci implique que le décodeur soit dans le périphérique d'affichage
(donc la télé, généralement) et que aucune donnée numérique ne
puisse être visible en clair, y compris sur les bus de la carte mère:
j'ai déjà vu des gens espionner des bus pour essayer de comprendre ce
que faisait un programe... Et bien sur, ça implique que le soft ne puisse
pas non plus être obtenu, y compris en essayant de disséquer un soft de
mise à jour obtenu légalement.

Pas forcément : on peut avoir le soft, et ne pas pouvoir décoder les
flux. Par exemple Windows Media Player contient tout ce dont on a
besoin pour décoder des WMA protégés, et on ne peut rien en faire.
Idem pour PGP par exemple.

Techniquement, tout ça est faisable, sans grand surcoût, d'ailleurs.
Personne ne l'a encore fait car les diffuseurs se contentent des solutions
existantes et passent leur temps à expliquer aux ayants-droits que leurs
solutions sont fiables et à la pointe de la technique (enfin, c'est, je
pense, la raison).

Pour la télé broadcast, on ne fait pas de DRM, mais du contrôle
d'accès. C'est pas tout à fait la même chose. Pour faire du DRM, on a
besoin de voie montante.

Si tu met en oeuvre une solution de ce type, alors le
fait que tu décrypte dans du hard sécurisé ou en soft n'a aucune
importance, les deux solutions deviennent équivalentes en terme de
sécurité, puisque on ne peut jamais accéder de quelque manière aux
données. Le choix est alors juste un problème de coût et
d'évolutivité. Je pense que, pour ces critères, la solution soft est de
loin préférable.

Oui.

--
Nous lançons une grande pétition pour pousser UFD à sortir Star Wars
Episode I en France en même temps qu'aux Etats Unis... C'est réaliste et
peu coûteux...Que la force soit avec vous.
-+- FN in : <http://www.le-gnu.net> - le coté obscur du neuneu -+-

On Mon, 27 Sep 2004 10:15:03 +0200, Stephane Dupille wrote:

Il n'y a aucune POC contre les DRM, ne déformez pas mes propos.
J'ai oublié le smiley, effectivement.

Mais ce que je disais reste valable: il n'existe personne capable
d'apporter la moindre preuve de la protection contre la copie grâce à
une DRM, puisque ça n'est à ce jour par envisageable.
Et pourtant, ça marche.

Sur les prospectus publicitaires, oui. Du moins, pour ce qui se fait

aujourd'hui.

Alors citez-moi une source sérieuse qui indique une faille dans les
systèmes DRM (hors ceux d'Apple qui sont troués).

Il y a juste besoin de réfléchir un peu:
l'argument de vente de la DRM c'est que ça protège le contenu. Or,
aujourd'hui, il n'y a aucun système sur le marché qui empêche
réellement de copier le contenu.
De plus, la "sécurité" des DRM actuelles reposent uniquement sur le fait
que le format est secret. L'expérience montre que toute sécurité basée
sur le secret est toujours percée, ce n'est qu'une question de temps.
Le jour ou les DRM seront basés sur des théorèmes mathématiques et
seront documentées comme telles (comme le sont les formats
cryptographiques), on pourra commencer à y croire. Tant que ça repose
sur le secret, c'est déjà une preuve que les gens qui concoivent ces
systèmes savent que si le secret est percé, la protection (déjà
relative) n'existe plus. Et le but d'une DRM qui marcherait bien, c'est
qu'on ne puisse jamais dupliquer le flux sans controle, par quelque moyen
que ce soit, ce que personne n'assure aujourd'hui.
Je ne dis pas que ce n'est pas faisable, je dis qu'aucune DRM existante
n'assure celà à ce jour.

Et s'il n'y a pas de module DVB ?
S'il n'y a pas de module DVB-CI, il faut bien en effet le faire en soft.

Parce que le module DVB ne contient pas de soft peut-être ?

Effectivement, il contient un DSP qui a son propre soft. Celui-ci n'est
pas visible, et pas reflashable, en principe.

Il y a forcément du soft.
Les STBxxx décodent le MPEG2 en hard. Il y a du soft pour commander le

tuner et paramétrer le décodage, mais pas pour le décodage lui même.

Il y a forcément du soft, même dans une puce. Tout traitement
informatique (sur le modèle de Von Neumann, le seul qui existe à
l'heure actuelle) nécessite une puissance de calcul (un CPU) et du
soft. Ou alors vous avez une set-top-box quantique.

Même dans un ordinateur quantique, il y aurait du soft...

Il existe bien entendu des puces spécialisées, qui embarquent le
soft, mais le soft existe toujours. Une carte à puce embarque du soft.
Un processeur type Intel ou PowerPC intègre bien plus de soft que vous
ne pouvez l'imaginer. Ce n'est pas parce que vous parlez d'une puce
spécialisée qu'elle n'a pas de soft.

Je le sais parfaitement. Je voulais souligner la différence entre le soft
éxecuté par le CPU et celui intégré (parfois downloadé au
démarage...) dans les chips. Le hard spécialisé se présente au
développeur comme une boite noire avec une API hardware. Ca ne veut pas
dire qu'il n'y a pas de soft, ça veut dire qu'on ne peut pas intervenir
directement sur ce soft et donc que le fait qu'il y ait du soft ou que les
fonctions soient cablées n'a aucune importance.
Mais ça n'a pas de rapport avec le problème...

Si c'est du MPEG 4, il faut le faire en soft et bien optimiser: le plus
rapide plafonne, je crois, à 262 Mhz.

On peut décoder du MPEG avec ce qu'on veut.

Je te met au défi de décoder du MPEG en plein écran sur un MPC850 à 30
Mhz... C'est un PPC complet, pourtant...

[...]

Sinon, j'aimerai bien que tu m'explique comment faire des calculs
sans CPU ? Un décodeur, c'est aussi con qu'un PC : il a un CPU qui
fait tourner un soft, un peu de RAM, une mémoire de masse pour stocker
les softs et basta.
Je n'ai pas parlé de faire faire des calculs sans CPU, j'ai parlé

d'utiliser du hard spécialisé et (en principe, je ne sais pas ce que
font les fondeurs en pratique...) sécurisé.

C'est donc un CPU, CQFD. Que ce soit spécialisé ou pas, c'est un
CPU.

Je parlais de CPU au sens de la définition: "Central Processing Unit".
Les modules spécialisés sont généralement des DSP qui peuvent être
qualifiés de coprocesseurs, c'est très rare qu'ils soient utilisés
comme CPU (sans processeur principal, donc), sauf dans les applications
embarqués industrielles (calculateurs de bord, ...).

Au fait, les calculateurs spécialisés (comme les DSP) sont des CPU.
Je crois que c'est sur ce point que nous divergeons.
Je suis tout à fait d'accord mais ce que j'appelle le CPU c'est, comme

son nom l'indique, le processeur central de la set-top-box.

D'accord, mais c'est souvent lui qui sert à communiquer avec la
carte à puce, et ainsi transférer les clés.

En pratique, pas forcément.

[...]

Ce n'est pas parce que ce n'est pas de l'IP qu'on ne peut pas utiliser du
hard spécialisé (y compris un module de type DVB-CI) et sécurisé pour
décrypter.

Bien entendu, mais maintenant qu'on a des CPU qui sont assez
puissant pour le faire, on ne va pas se géner pour l'utiliser. C'est
beaucoup moins cher comme ç.

Combien coute un PPC générique ? On peut trouver des CPU entre 100
et 300 Mips intégrant les décodeurs MPEG pour quelques ¤, c.a.d.
généralement bien moins cher qu'un processeur générique et consomant
quelques Watts (contre 11 Watts minimum pour le 750 pour mobile, je
crois). Je ne suis pas très convaincu par l'argument du prix.... Surtout
qu'après, il y a le coût du développement du soft...

[...]

Sinon, encore faut-il récupérer les clés (ce qui n'est pas aussi
facile que tu semble le dire)
C'est assez trivial, pourtant, quand tu sais comment communique une carte

à puce.

Encore faut-il avoir les équipements qui vont bien. Je ne dit pas
que c'est impossible, je dit que ce n'est pas aussi trivial que ça.

Si les clés sont exploitées par le processeur principal, ce n'est que du
soft. Pas besoin d'équipement, ce qui simplifie beaucoup le problème...

[...]

et ensuite, la clé est changée toutes les quelques secondes.
Si vous le faites si fréquement, bravo, mais les intervalles de

renouvellement des clés dans des flux réels (je veux dire utilisés en
production aujourd'hui) sont bien plus grand que celà.

Toutes les 10 (dix) secondes en production chez les principaux
opérateurs du cable et du satellite. Du moins les flux que la boite
dans laquelle je travaille protège.

Tu n'as pas intérêt à avoir d'erreurs de transmition, sinon, il risque
d'y avoir des coupures en permanence, non ?

[...]

Bof, il suffit souvent de se brancher derrière le décodeur ou le
module DVB pour sortir un flux numérique en clair. T'as pas besoin de
te faire chier à récupérer la clé. C'est comme pour contourner les
DRM, il vaut mieux graver.
Je ne prétends pas que le module dédié soit la panacée, je dis que

c'est déjà mieux que le décryptage soft par le CPU. Il faut quand même
bidouiller du hard pour récupérer le flux entre le module et le
décodeur MPEG (qu'il soit en hard ou en soft...), alors que l'autre
méthode nécessite juste de faire tourner un soft qui pirate les clés ou
le flux, ce qui est bien plus simple.

Ce n'est pas forcément plus simple. Et encore faut-il pouvoir
injecter le soft. Enfin, entendons-nous bien : on peut injecter du
soft, mais le faire sans faire pêter le soft déjà présent est très
compliqué ! Ça revient a faire du reverse-engeniering, et une fois
qu'on l'a fait, on n'a plus besoin d'injecter du code.

Hum, j'ai vu, plutôt à mes dépends, quelqu'un dumper des flash et les
patcher.... Si le soft n'est pas stocké sur un support crypté et signé,
c'est trivial d'injecter du soft (pour le gars qui cherche). Une fois
qu'il l'a fait sur un hard, tout devient beaucoup plus simple...

C'est pas à la portée du premier venu.

Le gars que j'ai vu faire n'a pas une connaissance technique énorme.
C'est juste un bidouilleur...

[...]

Alors citez-moi une source sérieuse qui indique une faille dans les
systèmes DRM (hors ceux d'Apple qui sont troués).
Il y a juste besoin de réfléchir un peu:

Allons-y.

l'argument de vente de la DRM c'est que ça protège le contenu. Or,
aujourd'hui, il n'y a aucun système sur le marché qui empêche
réellement de copier le contenu.

Et WMRM c'est quoi ? Et Helix c'est quoi ? Sans parler des nouvelles
versions, Janus et Harmony. On peut effectivement copier, mais on ne
peut pas utiliser le contenu, car il faut une licence (qui elle seule
contient la clé) pour pouvoir l'utiliser, et cette licence est
incopiable.

De plus, la "sécurité" des DRM actuelles reposent uniquement sur le fait
que le format est secret.

Avec WMRM, Helix et les normes OMA, le contenu est chiffré avec des
algos classiques (AES principalement, et un algo asymétrique pour
Helix (RSA si ma mémoire est bonne)), c'est loin d'être secret, et on
sait que c'est sûr.

L'expérience montre que toute sécurité basée sur le secret est
toujours percée, ce n'est qu'une question de temps.

Oui. C'est la raison pour laquelle on n'utilise pas le secret pour
les technos DRM actuelles.

Le jour ou les DRM seront basés sur des théorèmes mathématiques et
seront documentées comme telles (comme le sont les formats
cryptographiques), on pourra commencer à y croire.

C'est déjà le cas.

Tant que ça repose
sur le secret, c'est déjà une preuve que les gens qui concoivent ces
systèmes savent que si le secret est percé, la protection (déjà
relative) n'existe plus. Et le but d'une DRM qui marcherait bien, c'est
qu'on ne puisse jamais dupliquer le flux sans controle, par quelque moyen
que ce soit, ce que personne n'assure aujourd'hui.

Avec les DRM actuelles, seule la clé est secrète, et elle est
protégée par d'autres algos asymétriques (un peu comme le
fonctionnement de PGP).

Je ne dis pas que ce n'est pas faisable, je dis qu'aucune DRM existante
n'assure celà à ce jour.

Si si. Il n'y a pas que FairPlay comme DRM. *Toutes* (à l'exception
de celle d'Apple, que je connais mal d'ailleurs) sont basés sur une
crypto forte.

<snip>

On peut décoder du MPEG avec ce qu'on veut.
Je te met au défi de décoder du MPEG en plein écran sur un MPC850 à 30

Mhz... C'est un PPC complet, pourtant...

On a un proto de STB avec juste un PowerPC et un DSP qui décode du
MPEG4 à la volée. Bon, il est limite quand même, dès fois il sature un
peu. ;-)

Si vous le faites si fréquement, bravo, mais les intervalles de
renouvellement des clés dans des flux réels (je veux dire utilisés en
production aujourd'hui) sont bien plus grand que celà.
Toutes les 10 (dix) secondes en production chez les principaux

opérateurs du cable et du satellite. Du moins les flux que la boite
dans laquelle je travaille protège.
Tu n'as pas intérêt à avoir d'erreurs de transmition, sinon, il risque

d'y avoir des coupures en permanence, non ?

Si on n'arrive pas à choper la clé, on n'arrive pas à avoir le flux
qui va avec, alors... ;-)

Pour les erreurs de transmission ponctuelles, je ne sais pas, mais
il y doit y avoir une redondance et des codes de correction d'erreur
quelque part. Mais plus on change souvent les clés, moins les coupure
seront longues.

--
NC> J'ai perdu tous mes messages reçus, alors, je n'ai plus ton nom.
BB>Curieux chez l'utilisateur d'OE 5 cette manie de perdre les messages
Mais non, c'est une des principales caracteristiques d'Outlook Express,
-+-RG in <http://www.le-gnu.net> : La cuisine au bug -+-

On Wed, 29 Sep 2004 10:18:42 +0200, Stephane Dupille wrote:

Alors citez-moi une source sérieuse qui indique une faille dans les
systèmes DRM (hors ceux d'Apple qui sont troués).
[...]

L'expérience montre que toute sécurité basée sur le secret est
toujours percée, ce n'est qu'une question de temps.

Oui. C'est la raison pour laquelle on n'utilise pas le secret pour
les technos DRM actuelles.

Le jour ou les DRM seront basés sur des théorèmes mathématiques et
seront documentées comme telles (comme le sont les formats
cryptographiques), on pourra commencer à y croire.

C'est déjà le cas.

Je veux les docs des DRM pour le croire.

Tant que ça repose
sur le secret, c'est déjà une preuve que les gens qui concoivent ces
systèmes savent que si le secret est percé, la protection (déjà
relative) n'existe plus. Et le but d'une DRM qui marcherait bien, c'est
qu'on ne puisse jamais dupliquer le flux sans controle, par quelque moyen
que ce soit, ce que personne n'assure aujourd'hui.

Avec les DRM actuelles, seule la clé est secrète, et elle est
protégée par d'autres algos asymétriques (un peu comme le
fonctionnement de PGP).

Oui, donc le décryptage est basé sur le secret de la clé qui doit donc
rester inconnu de l'utilisateur. Le seul moyen de faire celà, c'est
qu'elle soit dans le hard. En quoi les DRM utilisés dans les formats
lisibles par un ordinateur peuvent répondre à celà ?

Je ne dis pas que ce n'est pas faisable, je dis qu'aucune DRM existante
n'assure celà à ce jour.

Si si. Il n'y a pas que FairPlay comme DRM. *Toutes* (à l'exception
de celle d'Apple, que je connais mal d'ailleurs) sont basés sur une
crypto forte.

Et toutes les implémentations permettent aujourd'hui d'avoir le flux
décodé en clair visible, non ?
Le contraire n'est possible que si tu décrypte dans le hard qui "affiche"
(l'enceinte, dans le cas du son).

[...]

Si vous le faites si fréquement, bravo, mais les intervalles de
renouvellement des clés dans des flux réels (je veux dire utilisés en
production aujourd'hui) sont bien plus grand que celà.
Toutes les 10 (dix) secondes en production chez les principaux

opérateurs du cable et du satellite. Du moins les flux que la boite
dans laquelle je travaille protège.
Tu n'as pas intérêt à avoir d'erreurs de transmition, sinon, il risque

d'y avoir des coupures en permanence, non ?

Si on n'arrive pas à choper la clé, on n'arrive pas à avoir le flux
qui va avec, alors... ;-)

Hum, dans les flux broadcastés, que ce soit en DVB (terrestre ou
satellite) ou en IP (généralement en UDP, le surcout et la latence du
TCP le rendrent difficilement utilisables...), tu peux louper un paquet et
recevoir tous les autres. Il peut te manquer juste un bout de la clé et
avoir tout le reste.

Pour les erreurs de transmission ponctuelles, je ne sais pas, mais
il y doit y avoir une redondance et des codes de correction d'erreur
quelque part. Mais plus on change souvent les clés, moins les coupure
seront longues.

Dans tous les exemples que j'ai vu, les clés sont retransmises
régulièrement entre les changements, donc les coupures ne sont pas
longues s'il y en a. De plus, les nouvelles clés commencent à être
transmisent un peu avant le changement, ce qui fait que tu peut en louper
quelques unes sans avoir de coupure.
Il me semble que c'est indispensable, de toute façon, vu que les
méthodes de transport des données ne sont pas fiables à 100 %.

Le jour ou les DRM seront basés sur des théorèmes mathématiques et
seront documentées comme telles (comme le sont les formats
cryptographiques), on pourra commencer à y croire.
C'est déjà le cas.

Je veux les docs des DRM pour le croire.

Sur le site de Microsoft pour la techno Microsoft, sur le site de
RealNetworks pour Helix, et sur le site d'OMA pour les specs OMA v1 et
OMA v2 (mais je ne sais pas si cette dernière norme est publique ou
non).

Tiens, d'ailleurs, l'implémentation d'OMA v2 implique la mise en
place d'une PKI.

Avec les DRM actuelles, seule la clé est secrète, et elle est
protégée par d'autres algos asymétriques (un peu comme le
fonctionnement de PGP).
Oui, donc le décryptage est basé sur le secret de la clé qui doit donc

rester inconnu de l'utilisateur.

Oui.

Le seul moyen de faire celà, c'est qu'elle soit dans le hard.

Non. Ou alors il faut passer à Paladium, et c'est mal. Il n'existe
pas de puce pour le DRM dans les PC actuels. Et d'ailleurs, on s'en
passe, dingue non ?

Vous seriez effaré du nombre d'infos qui se cachent dans votre PC
sur lesquels vous n'avez pas accès.

En tout cas, transférer une licence d'un PC à un autre est loin
d'être trivial (du moins avec une autre techno qu'OMA v1 qui est très
rigolo au niveau sécu).

En quoi les DRM utilisés dans les formats lisibles par un ordinateur
peuvent répondre à celà ?

En protégeant la clé avec un autre système cryptographique.

D'ailleurs, chez Microsoft, c'est la sécurité par le bordel : WMP
est tellement bordélique, que je met au défi quiconque (même un ingé
Microsoft) de retrouver quoi que ce soit dans ce bordel. ;-)

Si si. Il n'y a pas que FairPlay comme DRM. *Toutes* (à l'exception
de celle d'Apple, que je connais mal d'ailleurs) sont basés sur une
crypto forte.
Et toutes les implémentations permettent aujourd'hui d'avoir le flux

décodé en clair visible, non ?

Non, aucune ne le permet, sauf de détourner les flux au niveau des
drivers (et Microsoft a même une parade pour éviter ça). Enfin, ça
dépend de ce que dit la licence évidemment.

Le contraire n'est possible que si tu décrypte dans le hard qui "affiche"
(l'enceinte, dans le cas du son).

Si vous voulez repiquer le flux au niveau de l'enceinte, vous ne
choppez que de l'analogique. Effectivement on ne chiffre pas jusque
là.


Bref, on *peut* faire de la sécurité en soft, des centaines de
personnes bossent dessus dans le monde (moi y compris), et ça marche
très bien, et c'est *raisonablement* sûr. Ces systèmes servent à
protéger des films de cul qui vont se balader sur le net, pas les
secrets de la NSA ! Tout le monde se fout que ce soit inviolable ou
non, tout ce qu'on demande à un système de DRM à l'heure actuelle,
c'est que la copie ne soit pas triviale, et pas à la portée d'un
gugusse de 12 ans qui se balade sur le net quand son père est boulot.

Quand bien même, le fait même que la sécurité ne repose pas sur du
hard dédié rende la chose faillible, cette faille reste *théorique*,
et on n'a encore la fameuse faille dans les différentes
implémentations. Et le jour où on aura un exploit, on changera les
clés et basta.

En plus, vous l'avez dit vous même : si on peut flasher le hard,
alors la sécurité est déjà compromise avec votre copain bidouilleur.

Enfin, il faut se placer dans un contexte commercial : c'est la DRM
telle qu'elle est faite à l'heure actuelle ou rien : personne ne va
changer son PC ou sa platine CD ou acheter des enceintes
DRM-certified-proof simplement pour faire plaisir aux majors et leurs
lubies sécuritaires. Il est *impossible* de placer du hard dédié
sécurité DRM dans l'électronique grand public, les PC encore moins.
Personne ne va racheter un PC à 1000 ou 2000 ¤ simplement pour pouvoir
télécharger de la musique sur internet, personne ! Pour vous en
convaincre, relisez les interviews de S. Jobs quand il parle de ce
sujet : la protection doit être simple, car le piratage est simple. Le
seul qui aurait pû imposer une DRM hardware sur son matos, c'est
Apple, car il contrôle la DRM, le matériel (en particulier les iPod)
et la boutique en ligne. Demandez-vous pourquoi il ne l'a pas fait
(voir à ce sujet les annonces faites par Apple à propos de la non
dispo d'une techno DRM dans les iPod 1G).

D'ailleurs, si les majors sont bien conscients d'une chose, c'est
d'éviter la débandade et le ridicule qu'ils se sont tapés quand ils
essayés de sortir les CD protégés contre la copie, et qu'ils se sont
mangés les assoces de consomatteurs sur le dos. En tout cas, c'est le
cas pour la plus grosse d'entre elles.

Alors on a la sécurité qu'on peut, avec les matos qui sont
actuellement en circulation. Paladium arrivera peut-être un jour, mais
ce n'est pas encore le cas. En attendant, on a des systèmes DRM qui
marchent bien, qui permettent d'endiguer très nettement la copie
illicite, et c'est tout ce qu'on leur demande. Le reste n'est
qu'enculage de mouches.

Si vous voulez maintenant protéger des secrets militaires (du genre
le général Gamelin est un con (© PD)), c'est pas une DRM que vous
utiliserez, mais une salle blanche avec cage de Faraday, fermée à clé,
et pas d'accès au net.

Si on n'arrive pas à choper la clé, on n'arrive pas à avoir le flux
qui va avec, alors... ;-)
Hum, dans les flux broadcastés, que ce soit en DVB (terrestre ou

satellite) ou en IP (généralement en UDP, le surcout et la latence du
TCP le rendrent difficilement utilisables...), tu peux louper un paquet et
recevoir tous les autres. Il peut te manquer juste un bout de la clé et
avoir tout le reste.

C'était une boutade !

< snip > pour le DVB et les flux IP, vous avez certainement raison sur
ce point.

--
Je n'ai pas envie de perdre mon temps à leur APD à la con. Mais j'ai
besoin du certificat qu'y est délivré, pour passer le permis. J'ai
entendu qu'on le trouvait sur Internet. Quelqu'un aurait-il des infos?
-+- DC in GNU : Neuneu s'achète une conduite -+-