Thomas SOETE a écrit :
Il reste donc f() l'inconne qui transforme A et B pour donner C. Tu soumet l'idée que f peut changer a chaque film, pourquoi pas, ça veut juste dire que f() doit transiter un jour ou l'autre et que donc on peut l'intercepter.
Tu raisonnes mal : f() ne transite jamais.
Tu nous dit que le flux MPEG4 transite quelquepart qui n'est pas récupérable par logiciel. Donc il transite possiblement dans le noyau pour atterrir dans la carte graphique pour s'y faire décoder
Oui.
On a donc trois axes de recherches : - un pilote falsifié de la carte graphique dumpant le flux qui lui est envoyé - un pilote noyau, celui-ci résidant dans le noyau il peut lire tout ce qui transite et donc dumper le flux mpeg4 - une machine virtuelle dans laquelle on fait tourner le windows, ce qui permet de voir toutes les E/S possible de l'OS et donc dumper le flux qui arrivera un jour ou l'autre sur la carte video
Non, sur Windows un logiciel de lecture vidéo peut se prémunir de tout cela. Là encore, tu affirmes des choses sur un sujet que visiblement tu ne maîtrises pas. Essaie de commencer tes phrases par "j'imagine que" ou de mettre du conditionnel plutôt que "il peut lire" ou "qui permet" , ce serait plus correct si tu es un chercheur avec une démarche scientifique :-)
Pour travailler dans un laboratoire de recherche d'informatique
En étant chercheur ou ingénieur ? et
regardant de près les problématiques de sécurité informatiques, je peux te dire qu'il n'y a _aucun_ algorithme sur à partir du moment où il tourne sur le cpu de la machine.
Wow. Tu parles ausssi du CPU qui est dans ta carte bancaire, là ??
Les seuls algo qui tiennent la route sont les algo de chiffrement reposant sur des problèmes mathématiques difficiles a résoudre. On peut parler de plusieurs centaines de milliers d'années pour explorer un espace de 256 bits.
Tu es gentil, le sujet de mon mémoire de fin d'étude à l'ENSEIHT en 1986 - car je suis ingénieur en informatique et maths appliquées, je suis tombé dans le marketing ensuite - c'étai la preuve de protocoles cryptographiques, alors j'ai probablement lu des papiers sur les travaux de Rivest, Shamir et Adleman bien avant toi :-)
Si tu veux t'y mettre sérieusement, commence déjà par : http://fr.wikipedia.org/wiki/Rivest_Shamir_Adleman
Donc si on est au milieu et qu'on a pas la clé, récupérer les données est très difficile (on a l'exemple de TrueCrypt qui a resisté à la NSA...). Mais comme là on se trouve a l’extrémité du tunnel avec 100% des données, c'est raté.
Si tu veux occuper ton labo, cherche à casser PUMit, mais tu y perdras un temps qui serait mieux employer à trouver des trucs trouvables :-)
Avec une grande capacité de stockage, on pourrait même imaginer faire tourner le windows dans un émulateur, enregistrer 100% des instructions machines executées pour pouvoir rejouer a sa guise le film.
Là tu as raison, mais je n'ai jamais dit qu'un film n'était pas rejouable. reste à construire cet émulateur et à l efaire tourner comme tu le dis :-)
Comme dit dans mes précédent mails, c'est pas simple mais pas impossible.
On est d'accord : et si ça prend 3 ans et coûte 1 millino d'euros, ce n'est un souci pour personne :-)
La seule tentative avec les contenu HD était l'HDCP où on déportait le flux chiffré jusqu'à l'écran. Il est donc impossible au niveau de la machine de récupérer le flux non chiffré. Or l'histoire a montré certaines clés sont tombées puis la master-key rendant la protection nulle.
C'est pour cela qu'un système sans clé et à algorithme aléatoire basé seulement sur des propriétés de A, qui se retrouvent dans B, est incassable, et que son éventuel "cassage pour un film" n'en compromet aucun autre.
-- Pierre --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
