FR 2845554 A1 20040409 FR 0212268 A 20021003 DISPOSITIF POUR UNE TRANSMISSION SECURISEE DE FICHIERS AUDIOVISUELS DE HAUTE QUALITE La présente invention concerne le contrôle du 5 traitement, de la diffusion, de la transmission et de la visualisation sécurisée de données audiovisuelles et de programmes de télévision, ou plus généralement de n'importe quel programme ou séquence multimédia utilisant un format de flux nominal de type MPEG, par des utilisateurs 10 autorisés et propose un système sécurisé pour le contrôle du traitement, de la diffusion, de la livraison, de l'enregistrement, de la copie privée et de la visualisation de programmes et de séquences audiovisuelles s ou multimédias interactifs. Le problème général est de fournir un dispositif capable de transmettre de façon sécurisée un ensemble de films de haute qualité visuelle à un format numérique de type MPEG (MPEG-1, MPEG-2, MPEG-4, etc.) ou d'un autre type à base d'ondelettes, en direct vers l'écran d'un ordinateur 20 personnel, un écran de télévision et/ou pour être enregistré sur le disque dur d'un boîtier reliant le réseau de télétransmission à l'écran de visualisation, tout en préservant la qualité audiovisuelle mais en évitant toute utilisation frauduleuse comme la possibilité de faire des 25 copies pirates de films ou de programmes audiovisuels enregistrés sur le disque dur du boîtier décodeur. L'invention permet également un contrôle sécurisé de l'utilisation des copies et des droits des oeuvres diffusées. En particulier, l'invention concerne la sécurisation des communications entre l'équipement client et le serveur destinée à empêcher une personne capable de lire la communication entre le client et le serveur de lire ou de copier le contenu multimédia. Avec les solutions actuelles, il est possible de transmettre des films et des programmes audiovisuels sous forme numérique via des réseaux de diffusion de type hertzien, câble, satellite, etc. ou via des réseaux de 5 télécommunication type DSL (Digital Subscriber Line) ou BLR (boucle locale radio) ou via des réseaux DAB (Digital Audio Broadcasting). Par ailleurs, pour éviter le piratage des oeuvres ainsi diffusées, ces dernières sont souvent cryptées par divers moyens bien connus de l'homme de l'art. Toutefois, l'inconvénient principal de toutes les solutions actuelles (TiVo Inc., W000165762) est qu'il faut transmettre non seulement les données cryptées vers les utilisateurs, mais également les clés de décryptage. La transmission des clés de décryptage pouvant se faire avant, 15 en même temps ou après la transmission des programmes audiovisuels. Pour augmenter la sécurité et donc la protection des oeuvres audiovisuelles contre une utilisation mal intentionnée, les clés de décryptage ainsi que les fonctions de décryptage des décodeurs audiovisuels peuvent 20 comporter des moyens de sécurité améliorés comme des cartes à puces ou autres clés physiques qui peuvent en option, être mises à jour à distance. Ainsi, les solutions actuelles appliquées à un boîtier décodeur avec possibilité d'enregistrement local de 25 programmes audiovisuels sous forme numérique sur un support quelconque de type disque dur ou autre type de mémoire, offrent à un usager mal intentionné, la possibilité de faire des copies non autorisées des programmes ainsi enregistrés, puisqu'à un moment donné, cet usager possède 30 avec son boîtier décodeur numérique, associé ou pas à des systèmes de cartes à puce, toutes les informations, programmes logiciels et données permettant le décryptage complet des programmes audiovisuels. En raison justement du fait qu'il possède toutes les données, l'usager mal intentionné aura la possibilité de faire des copies illégales sans que personne ne s'aperçoive de cette copie frauduleuse au moment o elle est faite. Une solution consisterait donc à transmettre tout 5 ou partie d'un programme audiovisuel numérique uniquement à la demande (services de vidéos et de programmes à la demande) à travers un réseau de télécommunication large bande part exemple de type fibre optique, ADSL, câble ou satellite, sans autoriser l'enregistrement local des 10 programmes audiovisuels. Ici, l'inconvénient est tout autre et provient des performances de ces réseaux qui ne permettent pas de garantir des flux continus de quelques mégabits par seconde à chaque usager, comme exigé par les flux MPEG qui nécessitent des bandes passantes de quelques 15 centaines de kilobits à plusieurs mégabits par seconde. Dans ces conditions, une solution consiste à séparer le flux en deux parties dont aucune ne serait utilisable seule. Dans cette optique plusieurs brevets ont été déposés. Ainsi, on connaît par le document W009908428 20 (Gilles Maton) un procédé de traitement multi-applicatif d'un terminal actif localisable dans lequel on réalise au moins une liaison avec un programme identifiable dédié à l'exécution d'une application, ledit programme dictant ses conditions d'exploitation au terminal pour la mise à 25 disposition des fonctions. Le terminal dialogue ponctuellement, par l'emploi d'une liaison, avec le centre de gestion pour la réalisation, si nécessaire, des entrées et sorties des capacités de ce dernier, le centre de gestion devenant esclave ou non du terminal au niveau de 30 l'applicatif vis-à-vis du programme entrant. Cette invention concerne également le procédé d'identification du programme et du terminal en exploitation. Ce procédé de l'art antérieur divise le flux en une partie servant à identifier l'utilisateur et une partie qui contient le programme à proprement parler. En particulier, ledit programme n'est pas inutilisable mais seulement verrouillé par la première partie. D'autre part, le document EP0778513 (Matsushita) 5 décrit un procédé permettant de prévenir l'utilisation illégale d'une information en y ajoutant une information de contrôle afin de vérifier les droits de l'utilisateur. Le système permet de savoir en permanence quelle partie de l'information est utilisée et par quel utilisateur et par 10 là de savoir si cet utilisateur est en position illégale ou pas. Ce procédé sécurise donc les données en y ajoutant des informations additionnelles qui dénaturent l'information initiale. Le document W00049483 (Netquartz) nous offre 15 également des procédés et des systèmes pour créer un lien entre les utilisateurs et un éditeur d'entités numérisées. Le procédé comprend l'une au moins des étapes suivantes: l'étape de subdiviser ladite entité numérisée en deux parties; l'étape de mémoriser une partie dans une zone 20 mémoire d'un serveur connecté à un réseau informatique; l'étape de transmettre l'autre partie à au moins un utilisateur disposant d'un équipement informatique; l'étape de connecter ledit équipement informatique audit réseau informatique; l'étape d'établir un lien fonctionnel 25 entre ladite première partie et ladite deuxième partie. Ces procédés et systèmes ne spécifient pas si la partie mémorisée sur le serveur peut être stockée par l'utilisateur ce qui permettrait à celui-ci de pirater ladite entité numérisée. Toujours dans cette approche, l'état de la technique le plus proche se retrouve dans les brevets d'HyperLOCK Technologies dont le plus pertinent est le document US05937164. Cette invention utilise la solution qui consiste à séparer le flux en deux parties dont la plus petite détient une information nécessaire à l'utilisation de la plus grande. Cependant, ce brevet n'est pas suffisant pour répondre au problème identifié. En effet, la suppression d'une partie du flux dénature le format du 5 flux, et ne peut donc pas être reconnu comme un flux standard, exploitable avec des applications logicielles générales. Ce procédé de l'art antérieur nécessite à la fois un logiciel spécifique côté serveur, pour la séparation des deux parties, et un autre logiciel 10 spécifique assurant non seulement la reconstruction du flux, mais également l'acquisition du flux principal et son exploitation selon un format propriétaire à la solution. Ce format propriétaire n'est pas le format initial du flux avant séparation en deux parties, dans cette solution 15 connue. Cette société a également déposé trois autres brevets: le document US5892825 reprend le brevet précédent mais dans un cadre moins large car les flux y sont toujours cryptés; le document US6035329 repose sur le même 20 principe, il concerne un procédé permettant la lecture d'un disque de type CD-ROM ou DVD-ROM conditionnellement à l'identification des droits par l'insertion d'une carte à puce sur laquelle les informations nécessaires à la lecture sont stockées. Ce procédé n'est encore pas suffisant pour 25 notre problème car il ne garantit pas que le flux modifié soit du même format que le flux originel. Le document US6185306 concerne un procédé de transmission de données cryptées depuis un site Web vers un ordinateur demandeur. Ce procédé permet cependant à l'utilisateur de disposer à 30 un moment donné de tous les outils nécessaires pour copier les données. Le brevet WO 01/97520 présente également des méthodes, des procédés et des dispositifs pour contrôler la transmission et l'enregistrement des contenus numérisés de type MPEG-2. Toutefois, ce brevet ne présente aucune spécificité pour les documents audiovisuels de type MPEG-4. De plus, la méthode est totalement inefficace pour les réseaux de télécommunication bas débit, car elle substitue 5 tout ou partie des images I dont le poids en octets est très coteux lors de la transmission du deuxième flux. Enfin, le document " Cryptographie des télécommunications " d'Henri Gilbert et Marc Girault, revue " pour la science ", Hors-Série JuilletOctobre 2002, pages 10 80 à 85, présente un système de sécurisation d'une carte à puce avec un certificat dynamique: une puce s'identifie auprès d'un gestionnaire d'accès en fournissant un identifiant et un certificat calculé en fonction de l'identifiant et d'une variable " question " envoyée par le 15 gestionnaire d'accès. Ce système garantit que si un individu clone une carte à puce dans le but de l'utiliser frauduleusement, le clone ne pourra pas s'identifier auprès du gestionnaire d'accès. Ce système est cependant limité pas son asymétrie. Afin de corriger ces différents défauts, l'invention concerne selon son acception la plus générale un procédé pour la distribution de séquences audiovisuelles selon un format de flux nominal constitué par une succession de trames, ledit flux sur lequel on procède, 25 avant la transmission à l'équipement client, à une analyse du flux pour générer un premier flux modifié, présentant le format d'un flux nominal, et présentant des images modifiées par la substitution de certaines données par des données de même nature mais calculées de manière aléatoire 30 ou par rapport à un algorithme, et un deuxième flux d'un format quelconque, comportant les données substituées et les informations numériques aptes à permettre la reconstruction dudit flux modifié, puis à transmettre séparément, en temps réel ou en temps différé les deux flux ainsi générés depuis le serveur vers l'équipement destinataire, et pour lequel on calcule sur l'équipement destinataire une synthèse d'un flux au format nominal en fonction dudit premier flux et dudit deuxième flux. Dans ce 5 procédé, l'étape de transmission dudit deuxième flux est sécurisée selon le procédé suivant: - une étape d'initialisation de la communication dans laquelle le client s'identifie auprès du serveur qui répond au client qui vérifie à son tour que le serveur 10 communique bien avec lui; - une étape d'échanges d'informations entre le client et le serveur o chaque message de la part du client est identifié auprès du serveur par un identifiant de client émis par le serveur et chaque message de la part du 15 serveur est identifié auprès du client par un identifiant de serveur émis par le client. Selon un mode de réalisation préféré, ledit identifiant de client est un nombre aléatoire généré par le serveur et transmis par le serveur au client et 20 l'identifiant de serveur est un nombre aléatoire généré par le client et transmis par le client au serveur. De préférence, le serveur génère un nouveau nombre aléatoire pour chaque message envoyé, ledit nombre aléatoire étant alors également un identifiant de la 25 réponse du client et que le client génère un nouveau nombre aléatoire pour chaque message envoyé, ledit nombre aléatoire étant alors également un identifiant de la réponse du serveur. Avantageusement, l'équipement client comprend un 30 lecteur de carte à puce et que ladite synthèse est réalisée en partie sur une puce électronique reliée à l'équipement client par ledit lecteur. Dans un mode de réalisation de l'invention, ladite puce électronique interdit la poursuite de ladite synthèse. Avantageusement, la puce utilise un nombre aléatoire associé à chaque message de l'équipement client pour identifier la réponse du serveur audit message et interdire ladite poursuite de la synthèse. Selon un mode de réalisation particulier de l'invention, toutes les communications entre l'équipement client et le serveur sont cryptées. Avantageusement, ledit cryptage est un cryptage à clés publique et privée faisant intervenir l'identifiant du 10 client auprès du serveur. De préférence, le client s'identifie auprès du serveur grâce à des données de référence concernant le numéro de série de l'équipement, l'identifiant de la carte à puce et l'identifiant de réseau du client. Dans un mode de réalisation particulier de l'invention, la carte à puce et le dispositif de synthèse inclus dans l'équipement client communiquent par une liaison sécurisée de la même façon que la liaison entre ledit serveur et ledit client: chaque message de la part 20 dudit dispositif de synthèse est identifié auprès de la carte à puce par un identifiant de dispositif de synthèse émis par la carte à puce et chaque message de la part de la carte à puce est identifié auprès du dispositif de synthèse par un identifiant de puce émis par le dispositif de 25 synthèse. Avantageusement, une partie du processus de synthèse du flux original est réalisé sur la carte à puce. La présente invention sera mieux comprise à la 30 lecture de la description d'un exemple non limitatif de réalisation qui suit, se référant aux dessins annexés o: *la figure 1 décrit l'architecture d'ensemble d'un système pour la mise en oeuvre du procédé selon l'invention; *la figure 2 représente un mode de réalisation particulier du système d'analyse et de synthèse de flux de type MPEG conforme à l'invention; Une description du fonctionnement général de la communication entre le serveur et le client est décrite ciaprès, en faisant référence aux figures 1 et 2. L'invention concerne un flux de données d'un format nominal, notamment mais non exclusivement un flux de type 10 MPEG (MPEG-1, MPEG-2, MPEG-4). Le principe général d'un procédé de sécurisation d'un flux audiovisuel est exposé ci-après. L'objectif est d'autoriser les services de vidéo à la demande et à la carte à travers tous ces réseaux de diffusion et 15 l'enregistrement local dans le boîtier décodeur numérique de l'usager. La solution consiste à conserver en permanence à l'extérieur de l'habitation de l'usager, en fait dans le réseau de diffusion et de transmission, une partie du programme audiovisuel enregistré, cette partie étant 20 primordiale pour visualiser ledit programme audiovisuel sur un écran de télévision ou de type moniteur, mais étant d'un volume très faible par rapport au volume total du programme audiovisuel numérique enregistré chez l'usager. La partie manquante sera transmise via le réseau de diffusion 25 transmission au moment de la visualisation dudit programme audiovisuel numérique préenregistré chez l'usager. La plus grande partie du flux audiovisuel sera donc transmise via un réseau de diffusion classique alors que la partie manquante sera envoyée à la demande via un réseau de 30 télécommunication bande étroite comme les réseaux téléphoniques classiques ou les réseaux cellulaires de type GSM, GPRS ou UMTS ou en utilisant une petite partie d'un réseau de type DSL ou BLR, ou encore en utilisant un sousensemble de la bande passante partagée sur un réseau câblé. Sur la figure 1, l'agencement d'interfaçage audiovisuel (8) est adapté pour relier au moins un dispositif d'affichage, par exemple un moniteur, un vidéo projecteur ou un dispositif de type écran de télévision 5 (6), à au moins une interface de réseau de transmission et de diffusion large bande (4) et à au moins une interface de réseau de télécommunication (10). Selon la présente invention, cet agencement est composé d'un module (8) comprenant principalement, d'une part, une unité de 10 traitement adaptée pour traiter, en particulier décoder et désembrouiller tout flux audiovisuel de type MPEG selon un programme logiciel de décodage et désembrouillage préchargé, de manière à l'afficher, en temps réel ou différé, de le stocker, de l'enregistrer et/ou de l'envoyer sur un 15 réseau de télécommunication et, d'autre part, au moins une interface d'écran (7) et une interface de connexion à un réseau local ou étendu (5) et/ou (9). Le réseau de transmission et de diffusion large bande (4) et le réseau de télécommunication (10) pouvant être confondus en un seul 20 réseau. Le disque dur du module (8) peut être utilisé comme mémoire tampon pour stocker momentanément au moins une partie du programme ou de la séquence audiovisuelle à afficher, en cas de visualisation différée ou de limitation 25 dans la bande passante du réseau de transmission. La visualisation peut être retardée ou différée à la demande de l'utilisateur ou du portail (12). Comme le montre la figure 1, l'interface de connexion (5) est reliée à un réseau de transmission et de 30 diffusion large bande (4) telle qu'un modem, un modem satellite, un modem câblé, d'une interface de ligne à fibre optique ou d'une interface radio ou infrarouge pour la communication sans-fil. il C'est par cette liaison classique de diffusion audiovisuelle que seront transmis les contenus des programmes audiovisuels comme des films. Toutefois, de façon à ne pas laisser faire de copies pirates, avant de 5 transmettre le contenu audiovisuel depuis le serveur (1) ou le portail (12) il est prévu de conserver une petite partie du contenu audiovisuel dans le portail (12). En cas de visualisation d'un programme audiovisuel en temps réel, cette petite partie du contenu audiovisuel 10 conservée dans le portail (12) sera également envoyée au module (8) via le réseau de télécommunication (10). Comme le montre la figure 1, l'interface de connexion (9) est reliée à un réseau de télécommunication étendu (10), directement ou par un réseau local servant de 15 réseau d'accès et est constitué par exemple d'une interface de ligne d'abonné (Réseau téléphonique analogique ou numérique, DSL, BLR, GSM, GPRS, UMTS, etc). Ainsi donc, les programmes audiovisuels sont diffusés de façon classique en mode multidiffusion 20 (" broadcast ") via le réseau de transmission large bande (4) de type hertzien, câble, satellite, numérique hertzien, DSL, etc. depuis le serveur (1) directement via la liaison (3bis) ou via le portail (12) via la liaison (2) et (3) vers le module décodeur (8) à travers la liaison (5). 25 Chaque programme audiovisuel ainsi diffusé peut être crypté ou non, et, conformément à la présente invention, les flux de type MPEG comportent des modifications au niveau de certaines images comme décrit ci-dessus. En fonction des paramètres choisis par l'usager ou des informations 30 transmises par le serveur de diffusion, certains programmes audiovisuels ainsi modifiés et incomplets sont enregistrés dans le disque dur du boîtier (8). Lorsque l'usager désire visualiser un programme audiovisuel ainsi enregistré dans le disque dur de son boîtier (8) il en fait la demande de façon classique au moyen d'une télécommande relié à son boîtier (8) qui se connecte alors automatiquement au portail (12) via la liaison (9) de type réseau local ou accès direct et à 5 travers le réseau de télécommunication (10) lui-même relié au portail (12) via la liaison (11). Tout au long de la visualisation du programme audiovisuel, les liaisons (9) et (11) restent établies et permettent au boîtier (8) de recevoir les fonctions et les paramètres de reconstitution 10 du flux modifié ou des images modifiées. Les fonctions et les paramètres de reconstitution du flux modifié ou des images modifiées transmis ne sont jamais enregistrés dans le disque dur du boîtier (8) car les images du flux audiovisuel reconstitué sont directement affichées sur 15 l'écran de visualisation (6) via la liaison (7) après avoir été traitées par le Lecteur du boîtier (8) à partir de sa mémoire locale volatile. Une fois traités et visualisés, les fonctions et les paramètres de reconstitution du flux modifié ou des images modifiées venant d'être transmis par 20 le portail (12) seront effacés de la mémoire volatile locale du boîtier (8). Selon un mode de réalisation particulier, le boîtier (8) comprend un lecteur de cartes à puce qui permettra au portail (12) d'authentifier l'usager 25 propriétaire du boîtier (8). Selon un mode de réalisation particulier, pour un contenu MPEG donné, la carte à puce contient ledit deuxième flux qui a été mémorisé par le portail (12). Si cela est autorisé, la carte à puce permet 30 également à l'usager d'effectuer des copies privées des programmes audiovisuels enregistrés sur le disque dur de son boîtier décodeur (8). Pour cela, si l'usager veut faire une copie privée d'un programme audiovisuel, il le fera de façon classique sur un magnétoscope via la liaison (7) qui relie le boîtier (8) à l'écran de visualisation (6). Toutefois, s'il désire conserver une copie privée dans le disque dur de son boîtier, il l'indiquera à son 5 boîtier (8) qui enregistrera l'information " copie privée " ainsi que les coordonnées de l'usager se trouvant sur la carte à puce, dans un champ particulier (84) de ce programme audiovisuel enregistré sur le disque dur (85) du boîtier décodeur (8). Ensuite, chaque fois que l'usager 10 voudra visionner cette copie privée, le boîtier (8) se connectera automatiquement au portail (12) et indiquera à ce dernier que l'usager veut faire une lecture de sa copie privée; en retour, si la lecture de la copie privée est possible pour cet usager qui possède cette carte à puce 15 reliée à ce boîtier (8), le boîtier décodeur (8) recevra alors informations modifiées et/ou manquants du premier flux ainsi que tous les autres paramètres permettant la visualisation du programme audiovisuel constituant la copie privée. La présente invention concerne également le boîtier physique (8) utilisé par le consommateur pour accéder aux données. Ce boîtier physique est situé au domicile de l'utilisateur. Il fournit un ensemble de fonctionnalités qui gèrent l'information appropriée à présenter selon la 25 sélection de l'audience et gère la connexion et la communication avec le serveur distant. Selon un mode de réalisation particulier le boîtier physique correspondant à l'agencement d'interfaçage audiovisuel (8) est réalisé comme un dispositif autonome 30 fixe avec disque dur intégré. Selon un mode de réalisation particulier le boîtier physique correspondant à l'agencement d'interfaçage audiovisuel (8) est réalisé comme un dispositif autonome portable (mobile) avec disque dur intégré et/ou lecteur de disques (CD, DVD, etc.). Selon un mode de réalisation particulier le boîtier physique autonome (8) comprend un lecteur de cartes à puce. 5 Selon un autre mode de réalisation particulier l'agencement d'interfaçage audiovisuel (8) est réalisé comme une carte additionnelle qui sera installée dans un ordinateur de type PC et sera reliée à au moins une interface de réseau de transmission et de diffusion large 10 bande (4) et à au moins une interface de réseau de télécommunication (10). Cette carte utilisera le disque dur de l'ordinateur PC pour l'enregistrement du premier flux, mais comportera son propre calculateur et sa propre mémoire volatile de façon à ne pas laisser à l'utilisateur du PC 15 mal intentionné le moyen d'accéder aux informations complémentaires comme les fonctions et les paramètres de reconstitution du flux modifié ou des images modifiées du deuxième flux. Selon la présente invention, les serveurs 20 audiovisuels et multimédia (1) et/ou (12) comprennent des moyens de codage, de transcodage et de brouillage de données audiovisuelles, en particulier des moyens d'ajouter des informations cryptographiques et de sécurité au début et tout au long des séquences. Il est enfin à noter que l'invention dégrade le flux MPEG du point de vue visuel jusqu'à ne plus permettre la reconnaissance des scènes transmises et affichées sans avoir accès aux données et caractéristiques complémentaires, mais reconstitue totalement le flux MPEG 30 dans l'agencement d'interfaçage audiovisuel (8) sans aucune perte. Bien que la présente invention soit plus particulièrement axée sur les données audiovisuelles, il est entendu que toute information multimédia interactive et toutes données interactives peuvent être traitées par le présent agencement et le présent système, les données audiovisuelles de type MPEG étant les plus élaborées. La présente invention sera mieux comprise grâce à la 5 description suivante présentant la base physique de la présente invention et en référence à la figure 2 du dessin en annexe représentant un mode de réalisation préféré de cette dernière en tant qu'exemple non limitatif de réalisation particulièrement bien adaptée pour les réseaux 10 câblés et de satellites. La modification du flux MPEG est décrite ici à titre d'exemple et elle peut prendre une autre forme. Cependant, pour une réalisation efficace de l'invention, il convient que la partie servant à reconstruire le flux 15 initial est de taille très petite par rapport au flux total, afin de permettre sa délivrance à la volée. D'autre part, le premier flux généré par le dispositif d'analyse (121) est un flux MPEG, de façon à ce que l'utilisateur puisse le visualiser sans pour autant apprécier le contenu 20 du flux du fait de la dégradation induite par ladite analyse. L'autre partie du flux MPEG modifié sera mémorisée dans la mémoire tampon (123) du portail (12). Pour chaque flux MPEG ainsi diffusé, le portail (12) 25 conservera dans une mémoire tampon (123) les modifications qui auront été apportées à ce flux MPEG par l'analyseur (121) du portail (12). Il est précisé que, pour un même flux d'entrée MPEG (101) le traitement du flux peut être différent pour chaque utilisateur (8) et/ou pour chaque 30 groupe d'utilisateurs (8). Ainsi, la mémoire tampon (123) du portail (12) comprend une zone de mémoire différente pour chaque utilisateur. La phase décrite ci-dessus correspond à la première phase de préparation du flux MPEG par le portail (12), à sa transmission via le réseau large bande (4) et à son enregistrement dans un décodeur (8). Ce décodeur peut alors afficher ce flux MPEG enregistré dans son disque dur (85). Pour cela, le système de synthèse (87) du décodeur (8) va 5 lire le fichier MPEG depuis son disque dur (85) et va l'envoyer vers un lecteur classique MPEG (81). Si aucune donnée complémentaire n'est reçue par le système de synthèse (87), alors le flux MPEG qui parvient au lecteur (81) est traité et affiché tel quel, ce qui provoque une 10 distorsion importante de l'affichage sur l'écran de visualisation (6). Par contre, comme le flux enregistré est bien un flux de type MPEG, le lecteur (81) ne fait aucune différence et affiche les informations sur l'écran de sortie (6) qui apparaissent bien comme des données d'un 15 flux vidéo MPEG mais totalement incohérentes à l'être humain qui regarde l'écran (6). Toute copie du flux MPEG en provenance du disque dur (85) du boîtier (8) produira le même effet visuel lors de sa restitution par un lecteur MPEG quelconque; toute utilisation de cette copie qui 20 serait mal intentionnée est donc vouée à l'échec. Dans un agencement particulier, le dispositif (8) comprend une liaison cellulaire vers un réseau GSM (10). Dans le dispositif décrit ci-dessus, l'invention concerne plus particulièrement le moyen de sécuriser la 25 connexion entre l'équipement client et le serveur. En effet, une personne malintentionnée peut se connecter sur le canal de communication entre le client et le serveur et avec l'algorithme approprié, reconstituer le flux originel. Pour cela, l'invention fait intervenir deux 30 mécanismes: - un mécanisme de cryptage des données de communication avec des paramètres connus seulement du serveur; - un mécanisme de décryptage des données par l'équipement client sur une carte à puce, ledit décryptage étant préalable à toute reconstitution du flux originel. Ces deux mécanismes permettent de vérifier à la 5 fois l'identité du client à chaque requête de celui-ci pour le serveur et le non-stockage des informations envoyées par le serveur. Pour ce dernier point, si l'utilisateur stocke les données envoyées par le serveur pour les utiliser plus tard, il ne pourra réaliser l'opération de décryptage dans 10 la puce car celle-ci utilise des données relatives à la date des données. L'invention sera mieux comprise à la lecture de la description d'un mode de réalisation de l'invention. Une première étape consiste à initialiser la 15 connexion entre le client et le serveur. Pour cela, lorsque le programme exécuté sur le client a besoin des informations complémentaires pour reconstituer le flux originel, il appelle automatiquement le serveur en fournissant les références du fichier audiovisuel qu'il 20 veut afficher. Il transmet également au serveur le numéro de série de l'équipement (" Set Top Box " ou carte intégrée à un ordinateur) et un identifiant de la carte à puce. Une " Set Top Box " est un équipement qui se raccorde à un dispositif d'affichage comme une télévision par exemple et 25 qui permet d'afficher des contenus audiovisuels. Le client fournit également au serveur son adresse sur le réseau, cette adresse pouvant être le numéro de sa ligne physique de télécommunication (ADSL, BLR, Câble, etc.). Pour démarrer le processus, la carte à puce du 30 client envoie un nombre aléatoire Ni dont le début du calcul dépend d'une fonction de l'appui sur une touche clé de sa télécommande (la touche " lecture " de préférence) et de l'heure. Ainsi, il est certain que le nombre Ni est complètement aléatoire, puisque l'heure de l'appui est imprévisible. Le numéro de série de l'équipement, l'identifiant de la carte à puce, le nombre Ni et l'identifiant de réseau 5 du client constituent les données de référence du client auprès du serveur. Celui-ci utilise les données de référence du client pour déterminer si ledit client est autorisé à lire le flux originel. Pour cela, dans un mode de réalisation particulier de l'invention, le serveur est 10 connecté à une base de données comportant les données de référence de tous les clients et les contenus audiovisuels que chaque client a le droit d'obtenir. Si le client est autorisé à télécharger la partie manquante du flux, le serveur prépare une réponse en: - choisissant un nombre aléatoire Ns qui est une fonction de Ni et de l'heure d'arrivée du message du client; envoyant un message contenant le nombre Ns crypté avec le nombre Ni, les données de référence du 20 client et une clé publique du client; Le serveur répond sur la ligne physique qui correspond au numéro qu'il a en mémoire, mais il ne répond pas sur la ligne de télécommunication qui a été utilisée par le client pour contacter le serveur. Cette méthode 25 classique permet de prévenir certaines attaques de pirates. Le nombre aléatoire Ns généré par le serveur est ensuite à son tour utilisé par le client pour répondre au serveur, et permet au serveur de contrôler la provenance de chaque requête lui parvenant. Le client reçoit la réponse et la décrypte avec sa clé privée à la manière de PGP (" Pretty Good Privacy ", algorithme de cryptage à clé publique), ses données de référence et le nombre Ni. Ce décryptage est effectué en partie dans la carte à puce (une partie du programme se trouve et est exécutée dans la carte à puce). Si le décryptage est valide, le client génère un 5 nouveau nombre aléatoire Nc calculé en fonction de l'heure d'arrivée du message du serveur et répond au serveur en cryptant sa réponse avec la clé publique du serveur, les données de référence du client, le nombre aléatoire Ns qu'il vient de recevoir du serveur; le client indique 10 également dans son message les références dudit 1er flux et la position temporelle qu'il est en train de décrypter. Une fois cette étape d'initialisation achevée, le client et le serveur dialoguent pour permettre le décryptage du contenu audiovisuel au fur et à mesure de sa 15 lecture. Cette boucle de dialogue sécurisée est décrite cidessous. Le serveur reçoit les données cryptées émises par le client et les décrypte avec sa clé privée et les données de référence du client, le dernier nombre aléatoire Ns 20 qu'il a émis et l'heure et la date du client du client. Le décryptage permet au serveur d'identifier la requête comme provenant du client prévu (grâce aux données de référence) et en réponse au dernier message du serveur (grâce au nombre aléatoire Ns). De plus, le serveur décrypte le dernier nombre aléatoire Nc généré par le client. Si la vérification est positive, le serveur envoie au client les données dudit deuxième flux attendues par le client. De plus, il génère un nouveau nombre aléatoire Ns calculé en fonction de l'heure d'arrivée du dernier message 30 du client. Le serveur construit alors un message o les données du deuxième flux et le nouveau nombre Ns sont cryptés avec la clé publique du client, les données de référence du client et le dernier nombre aléatoire Nc généré par le client et reçu par le serveur. La réponse du serveur se fait sur la ligne physique qui correspond au numéro qu'il en dans sa mémoire, mais il 5 ne répond pas sur la ligne de télécommunication qui a été utilisée par le client pour contacter le serveur Le client reçoit la réponse du serveur, et la décrypte en utilisant sa clé privée, le dernier nombre aléatoire Nc envoyé au serveur, les données de référence 10 du client. Le client reconstitue le flux original avec ledit premier flux préalablement chargé et la partie du deuxième flux qu'il vient de décrypter. Pour cela, une partie au moins du programme de 15 combinaison desdits premier et deuxième flux est exécutée dans la carte à puce de sorte qu'il n'est pas possible à un utilisateur mal intentionné (un pirate) de reproduire tout ou partie du flux d'origine. Cette partie peut être la vérification du nombre aléatoire Nc ou l'exécution de 20 certaines instructions qui permettent de recombiner lesdits flux pour reconstituer des signaux audio-visuels cohérents. L'arrêt de la procédure de décryptage par le client peut être décidé par le client (la carte à puce détecte des incohérences) ou par le serveur qui arrête d'envoyer les 25 données au client. Cet arrêt de la procédure peut se faire par la non exécution des programmes dans la carte à puce. La décision d'arrêter la procédure peut être décidée par la carte à puce, soit parce que le dialogue entre le client et le serveur présente des incohérences ou n'existe pas (car 30 du débranchement de la ligne de télécommunication entre le client et le serveur), soit parce que le dialogue entre le serveur et le client présente des incohérences au niveau des échanges (par exemple au niveau des nombres aléatoires Nc et Ns). Dans le cas d'arrêt de la procédure par la carte à puce, l'exécution des programmes dans le processeur du client sera perturbée puisqu'une partie du traitement (cotraitement) qui devait être exécutée dans la carte à puce ne le sera plus. Le client génère ensuite un nouveau message pour demander la suite dudit deuxième flux, cryptant ce message avec la clé publique du serveur, les données de référence du client, le nombre aléatoire Ns qu'il vient de recevoir 10 du serveur. Il inclut dans le message un nouveau nombre aléatoire Nc généré en fonction de l'heure d'arrivée du dernier message du serveur et il indique à nouveau dans son message les références dudit premier flux et la position temporelle qu'il est en train de décrypter. Si le client arrête la lecture du contenu multimédia (en appuyant sur la touche " Pause " par exemple), le processus est de nouveau initialisé et reprend dans sa phase d'initialisation lorsque l'utilisateur appuie de nouveau sur la touche clé précédemment citée 20 (" Lecture " par exemple). Optionnellement, l'étape d'identification du client auprès du serveur n'est pas réalisée et le cycle commence avec une demande de contenu audiovisuel accompagnée d'un nombre aléatoire généré en fonction de l'instant d'appui de la touche clé. Selon un mode de réalisation de l'invention, illustré figure 2, le contenu multimédia est diffusé comme suit. Lors d'une phase préparatoire, le flux MPEG (101) est analysé par le dispositif d'analyse (121) afin de 30 générer deux flux, le premier flux étant de même nature qu'un flux MPEG et diffusé par la sortie (122) et le deuxième flux consistant en des informations permettant la reconstitution du flux original. Le premier flux est transmis au client par le canal de communication (4) qui peut être un réseau de communication large bande ou un support physique (CD) par exemple. Le premier flux est stocké sur un support (85) relié à l'équipement client (un disque dur ou un CD par exemple). Le deuxième flux est stocké dans une mémoire tampon (123) sur le serveur. Il est transmis à la demande du client à travers le canal de communication (10). Le client reçoit le deuxième flux à travers la mémoire tampon d'entrée (86). Pendant la réception du deuxième flux, le dispositif de synthèse (87) reçoit le premier flux à travers le tampon de lecture (83) et utilise les deux flux pour reconstituer le flux initial. Le dispositif de synthèse (87) est contrôlé par la puce située sur la carte 15 à puce (82). Pour cela, les données arrivant dans le tampon d'entrée (86) sont transmises à la carte à puce (82) par la liaison (88). La communication du deuxième flux selon l'invention comporte une phase d'initialisation et une phase de dialogue. Lors de la phase d'initialisation, - l'équipement client (8) transmet au serveur portail (12) ses données de référence, l'identifiant de la séquence demandée, la position temporelle dans ladite séquence et un nombre aléatoire Ni calculé par la carte à 25 puce (82) en fonction de l'instant d'appui sur la touche " Lecture " de la télécommande de son équipement par l'utilisateur; - le serveur (12) compare les données de référence du client avec des données enregistrées dans une 30 base de données (124) reliée au serveur (12); il enregistre également le nombre aléatoire Ni; - si le client a le droit de visionner la séquence demandée, le serveur (12) génère un premier nombre aléatoire Nsl en fonction de l'heure d'arrivée du message du client et encrypte ce nombre avec la clé publique du client, les données de référence du client et le nombre Ni; le client (8) reçoit le message du serveur (12) et le fait traiter par la carte à puce (82), celle-ci décrypte le nombre aléatoire Nsl avec la clé privée du client, ses données de référence et le nombre Ni; - si le décryptage est réussi, cela veut dire que le dialogue client-serveur fonctionne parfaitement 10 puisque le nombre Ni transmis par le serveur (12) est le même que le dernier nombre Ni généré par la carte à puce (82); le client prend donc en compte le nombre Nsl envoyé par le serveur; - la carte à puce (82) du client (8) génère un nouveau nombre aléatoire Ncl calculé à partir de l'heure d'arrivée du message du serveur et encrypte ce nombre avec le nombre Nsl qu'elle a décrypté, la clé publique du serveur et les données de référence du client. Le message ainsi formé est envoyé au serveur (12). - Le serveur (12) décrypte le message du client et vérifie que le Nsl envoyé par le client correspond au Nsl qu'il avait généré. Si ce n'est pas le cas, le serveur interrompt la transmission du contenu audiovisuel. Si c'est le cas, le processus entre dans une 25 boucle décrite ci-dessous qui peut être interrompue par le client et/ou le serveur. La boucle de dialogue entre le client et le serveur est décrite ci-après: - le serveur (12) génère un message comprenant la partie du deuxième flux attendue par le client, le nombre Nci qu'il a décrypté et un nouveau nombre aléatoire Nsi+1 calculé en fonction de la date d'arrivée du dernier message du client. Ce message est crypté avec la clé publique du client, les données de référence du client et le nombre aléatoire Nci que le serveur a décrypté dans le dernier message du client; - Le client reçoit le message, la carte à puce (82) décrypte le message et vérifie la valeur de Nci 5 de la même manière que pour le nombre Ni décrite ci-dessus. Si la vérification est positive, la puce (82) autorise le dispositif de synthèse (87) à traiter les données du deuxième flux afin de reconstituer le flux original. La puce (82) décrypte également le nombre Nsi+l et le stocke 10 pour l'émission du message suivant. - La puce (82) génère un nouveau nombre aléatoire Nci+l et le client (8) encrypte un message contenant le nombre Nci+l, les données du deuxième flux nécessaires au dispositif de synthèse (87), encryptés avec 15 la clé publique du serveur, les données de référence du client et le nombre Nsi+ l. Ce message est envoyé au serveur (12). - Le serveur (12) reçoit le message du client et le décrypte avec sa clé privée, les données de référence 20 du client et le nombre Nsi+l. Si le décryptage est réussi, le nombre Nsi+1 est alors correct et le processus est autorisé à continuer. Dans un mode de réalisation particulier de la 25 présente invention, le procédé comprend en outre une étape de sécurisation des communications entre la carte à puce intégré à l'équipement client et le module de lecture (" Lecteur ") exécuté par un processeur (86) relié à la carte à puce par une liaison interne (88). Pour cela, une partie du programme de recomposition du flux initial à partir desdits deux flux est réalisée sur la carte à puce. Pour cela, le " Lecteur " (87) et la carte à puce sont reliés par la liaison (89). Les calculs sont réalisés par la puce tant que la carte à puce communique avec le serveur (12) distant. Ainsi, si une vérification d'un des nombres aléatoires Nci générés et vérifiés par la puce échoue, la puce interrompt la communication avec le serveur (12). L'interruption de cette communication 5 entraîne l'interruption du traitement de recomposition des flux par la puce, et la recomposition desdits deux flux est ainsi non réalisée puisque le co-traitement que doit exécuter la carte à puce (82) ne se fait pas et que les données attendues par le module (86) et le lecteur (87) via 10 les liaisons (89) et (88) ne seront pas transmises par la puce (82). De plus, le module (86) et la puce (82) d'une part et le " Lecteur " (87) et la puce (82) d'autre part communiquent sur une liaison sécurisée (89) et (88) de la 15 même manière que la liaison entre le serveur (12) et le client (8): Avec chaque message, la carte à puce génère un nombre aléatoire Ncp calculé en fonction de l'heure d'arrivée du dernier message venant du " Lecteur " (87) et 20 envoie un message contenant des informations sur le traitement des flux et le dernier nombre aléatoire Ncp, ces deux informations étant cryptées avec la clé publique du " Lecteur ", des données dites de référence, connues de la puce et du " Lecteur " et le dernier nombre aléatoire Nl 25 reçu du " Lecteur ". Au message suivant venant du " Lecteur ", la puce décrypte le message avec sa clé privée, les données de référence et le dernier nombre Ncp qu'elle a émis. Tant que le décryptage est réussi, la puce maintient la communication avec le " Lecteur ". Si le 30 décryptage échoue, la puce interrompt la communication. Dans un mode de réalisation particulier, si le décryptage échoue, la puce redemande le message au " Lecteur " une ou plusieurs fois avant d'interrompre la communication. Avec chaque message, le " Lecteur " génère un nombre aléatoire Ni calculé en fonction de l'heure d'arrivée du dernier message venant de la carte à puce et envoie un message contenant des informations sur le 5 traitement des flux et le dernier nombre aléatoire Nl, ces deux informations étant cryptées avec la clé publique de la carte à puce, des données dites de référence, connues de la puce et du " Lecteur " et le dernier nombre aléatoire Ncp reçu de la carte à puce. Au message suivant venant de la 10 carte à puce, le " Lecteur " décrypte le message avec sa clé privée, les données de référence et le dernier nombre Nl qu'il a émis. Tant que le décryptage est réussi, le " Lecteur " maintient la communication avec la puce. Si le décryptage échoue, le " Lecteur " interrompt la 15 communication. Dans un mode de réalisation particulier, si le décryptage échoue, le " Lecteur " redemande le message à la puce une ou plusieurs fois avant d'interrompre la communication. REVENDICATIONS 1. Procédé pour la distribution de séquences audiovisuelles selon un format de flux nominal constitué 5 par une succession de trames, ledit flux sur lequel on procède, avant la transmission à l'équipement client, à une analyse du flux pour générer un premier flux modifié, présentant le format d'un flux nominal, et présentant des images modifiées par la substitution de certaines données 10 par des données de même nature mais calculées de manière aléatoire ou par rapport à un algorithme, et un deuxième flux d'un format quelconque, comportant les données substituées et les informations numériques aptes à permettre la reconstruction dudit flux modifié, puis à 15 transmettre séparément, en temps réel ou en temps différé les deux flux ainsi générés depuis le serveur vers l'équipement destinataire, et pour lequel on calcule sur l'équipement destinataire une synthèse d'un flux au format nominal en fonction dudit premier flux et dudit deuxième 20 flux caractérisé en ce que l'étape de transmission dudit deuxième flux est sécurisée selon le procédé suivant: - une étape d'initialisation de la communication dans laquelle le client s'identifie auprès du serveur qui répond au client qui vérifie à son tour que le serveur 25 communique bien avec lui; - une étape d'échanges d'informations entre le client et le serveur o chaque message de la part du client est identifié auprès du serveur par un identifiant de client émis par le serveur et chaque message de la part du 30 serveur est identifié auprès du client par un identifiant de serveur émis par le client. 2. Procédé pour la distribution de séquences audiovisuelles selon la revendication 1, caractérisé en ce que ledit identifiant de client est un nombre aléatoire généré par le serveur et transmis par le serveur au client et l'identifiant de serveur est un nombre aléatoire généré par le client et transmis par le client au serveur. 3. Procédé pour la distribution de séquences audiovisuelles selon la revendication 2, caractérisé en ce que le serveur génère un nouveau nombre aléatoire pour chaque message envoyé, ledit nombre aléatoire étant alors 10 également un identifiant de la réponse du client et que le client génère un nouveau nombre aléatoire pour chaque message envoyé, ledit nombre aléatoire étant alors également un identifiant de la réponse du serveur. 4. Procédé pour la distribution de séquences audiovisuelles selon l'une des revendications précédentes, caractérisé en ce que l'équipement client comprend un lecteur de carte à puce et que ladite synthèse est réalisée en partie sur une puce électronique reliée à l'équipement 20 client par ledit lecteur. 5. Procédé pour la distribution de séquences audiovisuelles selon la revendication 4, caractérisé en ce que ladite puce électronique interdit la poursuite de 25 ladite synthèse. 6. Procédé pour la distribution de séquences audiovisuelles selon l'une des revendications 4 ou 5, caractérisé en ce que la puce utilise un nombre aléatoire 30 associé à chaque message de l'équipement client pour identifier la réponse du serveur audit message et interdire ladite poursuite de la synthèse. 7. Procédé pour la distribution de séquences audiovisuelles selon l'une quelconque des revendications précédentes, caractérisé en ce que toutes les communications entre l'équipement client et le serveur sont cryptées. 8. Procédé pour la distribution de séquences audiovisuelles selon la revendication 7, caractérisé en ce que ledit cryptage est un cryptage à clés publique et 10 privée faisant intervenir l'identifiant du client auprès du serveur. 9. Procédé pour la distribution de séquences audiovisuelles selon l'une quelconque des revendications 15 précédentes, caractérisé en ce que le client s'identifie auprès du serveur grâce à des données de référence concernant le numéro de série de l'équipement, l'identifiant de la carte à puce et l'identifiant de réseau du client. 10. Procédé pour la distribution de séquences audiovisuelles selon l'une quelconque des revendications précédentes, caractérisé en ce que la carte à puce et le dispositif de synthèse inclus dans l'équipement client 25 communiquent par une liaison sécurisée de la même façon que la liaison entre ledit serveur et ledit client: chaque message de la part dudit dispositif de synthèse est identifié auprès de la carte à puce par un identifiant de dispositif de synthèse émis par la carte à puce et chaque 30 message de la part de la carte à puce est identifié auprès du dispositif de synthèse par un identifiant de puce émis par le dispositif de synthèse. 11. Procédé pour la distribution de séquences audiovisuelles selon l'une quelconque des revendications précédentes, caractérisé en ce qu'une partie du processus de synthèse du flux original est réalisé sur la carte à puce.