devloop :: blog

Après le DVD, le WMA, la protection AACS des disques Blu-Ray ou encore le RTMPE d'Adobe, un autre DRM a été mis en échec.

Il s'agit du HDCP (pour Protection des contenus numériques haute définition) qui est utilisé pour chiffrer les données qui transitent entre équipements "lisant" le HDMI.
Comme tout DRM, l'objectif de cette protection est de contrôler par où passent les flux HDMI, ne rendant leur lecture possible que sur du matériel qu'une autorité (composée de multinationnales diverses) aura validée.

Le tout fonctionne grace à un système cryptographique basé sur des clés.

En l'occurence, la clé cryptographique maître du HDCP a été révélée. Ainsi n'importe qui pourra créer un logiciel ou du matériel capable de lire du HDMI sans avoir à réclamer une clé valide auprès de l'autorité et sans avoir à suivre les restrictions qui lui seraient imposées.

L'origine (non révélée) de la clé pourrait être liée à une faiblesse cryptographique découverte en 2001, il y a 9 ans.
La clé a été mise en ligne sur Pastebin.com et reprise en article sur ce site.

Je l'ai aussi mise en ligne ici.

Deux articles en français traitant du sujet :
PC INpact - La Master Key du HDCP serait révélée : la fin de ce DRM ?
Numerama - HDCP : le DRM des contenus numériques haute définition aurait été cassé

Edit : Intel qui est à l'origine de l'algo HDCP a confirmé auprès de FoxNews que la clé master publiée est valide. Ils minimisent aussi l'impact de cette fuite car selon eux il faut aussi pouvoir créer une puce (hardware) pour décoder les données à partir de cette clé.
Mais rien n'indique qu'on ne trouvera pas d'ici quelques temps des décodeurs au marché noir...

edit 2 : Intel brandit la menace du DMCA pour faire fermer les sites diffusant la clé

J'ai déjà parlé du protocole RTMPE, protocole de streaming propriétaire de chez Adobe, dans un billet sur M6 Replay ainsi qu'une façon de passer outre les sécurités du protocole en utilisant un logiciel spécifique.

J'avais aussi connaissance de "rtmpdump", petit logiciel en ligne de commande qui permet de télécharger les flux RTMP sur différents sites. Pendant un moment je suivais son développement de près puis m'en était petit à petit éloigné en me disant que si un jour le RTMPE, la version chiffrée du RTMP, était implémentée, j'en entendrais forcément parler d'une manière quelconque.

Et c'est arrivé
Un lisant cet article de Slashdot, on apprend qu'une spécification non-officielle a été créée en se basant sur le code source de rtmpdump.
La réaction d'Adobe a consisté à utiliser le DMCA (loi sur le droit d'auteur) pour forcer SourceForge à retirer de ses pages le projet rtmpdump qui y était hébergé.

L'implémentation de RTMPE dans rtmpdump n'est pourtant pas si récente. Si on regarde dans le ChangeLog du logiciel, on voit que le code a été rendu publique le 27 avril de cette année par la version 1.5.
On comprend l'agacement d'Adobe qui tenait secret les spécifications de RTMPE et vend ses solutions (serveurs de streaming) à un certain prix faisant tout pour que des solutions libres comme le serveur Red5 ou le player Gnash ne parlent que le RTMP qui est "non protégé".

Toutefois je n'ai pas encore jeté un oeil sérieux au support du RTMPE dans rtmpdump ainsi qu'à la spécification (qui commencent tous deux à se répliquer sur Internet dans un mouvement d'anti-censure avec en plus SF qui est montré du doigt) pour déterminer s'il est possible de télécharger facilement les vidéos sur des sites de streaming basés sur les technos Flash ou si cela requiert des connaissances particulières...

Bref un buzz à suivre de très près et qui montre une fois de plus que les DRMs sont voués à l'échec.

Vous êtes peut-être au courant de l'existence d'une version béta de M6Replay qui permet aux utilisateurs de Linux et Mac de profiter des vidéos du site de M6.

Je m'étais déjà penché il y a quelques temps sur la version initiale (pour le moment toujours la version officielle) histoire de voir si il était possible de bricoler une "zapette" comme celle pour les émissions en clair de Canal+.
Après avoir pas mal fouillé, et trouvé assez facilement les urls des flux, il s'avérait que le protocole utilisait était du "RTSP-over-HTTP" (ou du moins quelque chose dans ces eaux là ), qu'on pouvait normalement le lire en bidouillant les options de VLC ou en passant un simple "mms://" au lieu du protocole dit officiel.
On final on avait bien de l'image et du son mais pas vraiment ce qu'on désirait. J'ai quand même cru discerner durant un dixième de seconde une paire d'yeux au milieu d'un artistique nuage jaune fluo et de taches oranges... à moins que ce soit l'effet du hazard
En fait il semblerait qu'un codec propiétaire (DRM-powered) soit utilisé en plus, rendant impossible la lecture sur les systèmes libres

Avec la version béta les vidéos sont bien lisibles sous Linux, mais M6 s'est visiblement cresé la tête pour trouver une solution tout aussi imbuvable.
Ca fonctionne donc avec le lecteur Flash (qui rappelons le est propriétaire)... mais pas autre chose.

On a bien un flux XML dans lequel on retrouve des urls du style
mp4:production/live/DIFF_28072008/H264_UN_DINER_PRESQ__UN_DINER_PRESQ__280720080615__LIVE.mp4
et en observant le traffic réseau on sait que le flux vidéo est lu depuis le serveur fcds98.lon.llnw.net (le nom de machine n'est probablement pas fixe) mais à part ça difficile de retrouver un lien direct pour y pointer son lecteur multimédia préféré.

Après recherches le flux vidéo utiliserait le protocole RTMP (Real Time Messaging Protocol), un protocole (bien évidemment) propriétaire développé par Macromédia (avant rachat par Adobe).
Il existe différents outils closed-source pour capturer les vidéos des flux RTMP, la majorité se basant sur le même principe que cette source C++ à savoir utiliser la librairie pcap et surveiller tout ce qui communique avec le port TCP 1935.

Le protocole RTMP a aussi été analysé et est utilisé par le projet "Open Source Flash" par le biais du serveur Red5.
Comble du bonheur, les versions béta de VLC (>= 0.9.*) supportent le RTMP

Petit problème : M6Replay utilise à priori le RTMPE ("RTMPE is a version of RTMP which is an 128-bit encrypted protocol"), ce qui fait que ces outils se montrent inefficaces.

Bref pour le moment seulement le lecteur Flash peut lire ces vidéos sous Linux. Il reste à trouver les adresses exactes des flux et attendre que le RTMPE soit supporté par un logiciel libre pour pouvoir en profiter "pleinement".

L'AACSLA continue d'utiliser son système de révocation des clés pour empécher la lecture de nouveaux disques haute définition sur des lecteurs dont les clés ont été rendues publiques.
La mise à jour vers ce que l'on appelle l'"AACS version 3" devrait être déployée dans ce but d'ici quelques jours, le 22 mai 2007, et être mise en place sur tous les supports HD-DVD et BluRay qui seront disponibles à la vente.

Mais c'était sans compter sur les développeurs du logiciel de déchiffrement AnyDVD qui proposent une version mise à jour de leur logiciel permettant d'effectuer une copie des médias protégés par AACS v3.
La nouvelle publiée sur Ars Technica nous informe que l'exploit est déjà "visible" par le biais des HD-DVD de Matrix 2 et 3 sortis en avance dans les rayons.

L'article de Ars Technica parle d'une nouvelle clé de volume trouvée par SlySoft, l'éditeur de AnyDVD, mais techniquement ça ne colle pas avec ce que l'on a vu jusqu'à présent.

Pour que SlySoft dévoile sa mise à jour à un tel moment, il fallait, comme le fait remarquer Freedom to Tinker, que l'éditeur ait gardé secrétement cette clé sous la main depuis un bon moment.
Je pense (et je ne suis pas le seul) que la clé en question doit plus correspondre à une Device Key, une clé qui est spécifique à (par exemple) une version d'un logiciel de lecture donnée. Les anciennes versions de AnyDVD se basaient apparemment sur des clés de PowerDVD. Evidemment, AnyDVD ne peut pas explicitement utiliser les clés d'un logiciel tiers. C'est pour cela que les clés qu'il utilise doivent être le résultat d'une opération combinant plusieurs clés à l'un des moment de l'algorithme AACS (l'AACS ce n'est pas seulement le jeu du chat et de la souris, c'est aussi jouer avec le feu sans jamais se bruler )

Le fonctionnement de AnyDVD est encore un mystère à l'heure actuelle mais déjà discuté sur Doom9. On en saura peut-être plus d'ici peu.

Quoiqu'il en soit, les pirates sont tellement en avance sur l'AACSLA qu'ils en sont à attendre les révocations pour pouvoir publier aussitôt les clés toujours fonctionnelles
L'AACSLA quand à lui continue inlassablement de révoquer ses clés et à menacer de poursuites judicaires puisqu'il n'a plus que ce moyen pour essayer de garder la "machine" en fonctionnement (et ses clients par la même occasion).

Autres articles relatifs à l'AACS :
devloop :: AACS cassé
devloop :: Informatique en vrac
devloop :: AACS de nouveau ridiculisé
devloop :: 09F911029D74E35BD84156C5635688C0
Certains ont trouvé une façon de réprésenter graphiquement la Processing Key en RGB :
http://en.wikipedia.org/wiki/Image:Free-speech-flag.svg
09 f9: A Legal Primer (EFF)
AnyDVD method of operation (date un peu)

En février dernier, un certain ATARI Vampire du forum Doom9 est parvenu à récupérer une (sub) Device Key du logiciel WinDVD.
C'est aussi par ce logiciel que plusieurs bidouilleurs se sont fait les dents sur la protection AACS et sont parvenus à la casser à plusieurs reprises.

Comme on pouvait s'y attendre, le groupe AACS Licensing Administrator a finalement eu recours au système de révocation de AACS en obligeant l'éditeur de WinDVD (InterVideo, filiale de Corel) à mettre à jour son logiciel qui incluera de nouvelles clés ainsi que de nouvelles protections anti rétro-ingénierie.

Le système de révocation est tel que les nouveaux disques HD-DVD ou BluRay seront illisibles sur l'ancienne version du logiciel WinDVD. Les utilisateurs se voient donc obligés d'effectuer une mise à jour de leur logiciels s'ils souhaitent continuer à regarder des films.
On se demande qui est le plus à plaindre dans cette histoire. Ce qui est sûr c'est que malgré toutes les protections qui pourront être ajoutées, ce ne sera qu'une question de temps avant que les nouvelles clés soient trouvées.
Ca n'a pas forcément d'utilité mais si les clés sont divulguées puis mises à jour sans cesse, les consommateurs vont probablement aller voir ailleurs et la société perdra vite sa crédibilité. Les pirates ont par conséquent en bon moyen de pression sur les éditeurs de logiciels.
Sans compter (et j'y reviens juste après) que les clés révoquées doivent être stockées sur les nouveaux disques et risqueraient de s'entasser, augmentant ainsi l'espace disque nécessaire pour placer un média protégé.

Bref c'est le jeu du chat et de la souris mais on se garde bien de la dire sur le site du AACSLA.

Quelques petites 24 heures plus tard, c'est le système de révocation en question qui est mis à mal par Geremia et arnezami sur le forum Doom9 et XBoxHacker BBS.

Geremia a effectué ses tests sur le lecteur HD-DVD de la Xbox. Il a d'abord cherché à identifier le firmware utilisé en comparant le chipset avec ceux existant puis en le désassemblant.
Après quelques heures d'analyse de code assembleur bizarre (FR30, kezako ?), il est parvenu à patcher le firmware pour retirer la procédure de vérification des clés révoquées.

Un peu plus tard, un certain xt5 a mis à disposition un programme qui va modifier le code en mémoire pour bypasser la vérification, ce qui évite la désagréable tâche d'avoir à flasher le disque.

Difficile de savoir qu'elle va être la réponse de l'AACSLA et de Microsoft. S'il faut obliger les utilisateurs à mettre à jour leur firmware ça peut être problématique

Clubic : Une nouvelle protection HD-DVD contournée
RegHardware : Hack exposes AACS 'hole'