Brevet FR2907287A1 — publié le 20080418

Procédés de transmission sécurisée d'un contenu, incluant une restriction d'accès à ce contenu, produit programme d'ordinateur, moyen de stockage, et dispositifs correspondants. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des réseaux de communication de données. Plus particulièrement, l'invention concerne la protection de contenus transmis entre plusieurs terminaux via un tel réseau. L'invention s'applique notamment, mais non exclusivement, dans le cas où le contenu est un flux de données de type audio-vidéo (AV), transmis sur un réseau multimédia. 2. ART ANTÉRIEUR Il existe des protocoles de protection de contenu basés sur une authentification de dispositifs et l'échange de contenu de façon cryptée entre ces dispositifs. On connaît par exemple le protocole DTCP (pour Digital Transmission Content Protection en anglais et protection de contenus en transmission numérique en français). Les caractéristiques et recommandations de ce protocole sont détaillées dans le document de référence suivant : Digital Transmission Content Protection Specification, Volume 1 et 2, Draft 1.29 . Avec ces protocoles, seuls les dispositifs authentifiés peuvent décrypter le contenu. Cependant, ces protocoles permettent d'effectuer une authentification au niveau dispositif, mais pas une restriction d'accès au niveau contenu. En effet, une fois qu'un premier dispositif s'est authentifié avec un second dispositif, le premier dispositif peut accéder à tous les contenus disponibles dans ou à travers le second dispositif, et inversement. Or, il existe un besoin de restreindre l'accès à certains contenus disponibles dans ou à travers un dispositif, particulièrement lorsque ce dispositif est interconnecté à une pluralité d'autres dispositifs tous authentifiés entre eux par un protocole de protection de contenu. Cette restriction est notamment utile pour offrir un service de gestion privée de contenus permettant seulement à certains utilisateurs l'accès à certains contenus dans le réseau de communication interconnectant les dispositifs. 2907287 2 Il existe dans l'état de la technique des méthodes pour gérer le caractère privé d'un contenu par l'application d'un double cryptage : - un premier cryptage de bout en bout, avec une première clé, appliqué entre le dispositif source et le dispositif destination. Côté source, l'utilisateur fournit, via 5 une interface du dispositif source, une information servant à la détermination de la première clé, ou la première clé elle-même. Côté destination, l'utilisateur fournit, via une interface du dispositif destinataire, cette même information, afin que le dispositif destinataire possède la première clé ; et - un second cryptage, selon un protocole de protection de contenu (DTCP par 10 exemple) et avec une seconde clé, appliqué entre les dispositifs intermédiaires authentifiés qui se trouvent sur le chemin entre les dispositifs source et destinataire. Ces dispositifs intermédiaires sont les noeuds du réseau via lequel les dispositifs source et destinataire sont interconnectés. Ainsi, le contenu est reçu par le dispositif destinataire avec seulement le premier 15 cryptage, le second cryptage ayant été enlevé (par exemple par le dernier noeud avant le dispositif destinataire). Ces méthodes connues possèdent un inconvénient majeur : le dispositif destinataire, qui peut être par exemple un dispositif d'affichage, doit posséder une interface permettant à l'utilisateur d'entrer une information servant à la détermination de 20 la première clé, ou la première clé elle-même. En effet, ceci est impératif pour que le contenu crypté avec la première clé soit exploité (c'est-à-dire lu) par le dispositif destinataire. Un autre inconvénient de ces méthodes connues est qu'il n'est pas possible d'utiliser un dispositif destinataire quelconque disponible dans le marché (par exemple 25 un téléviseur numérique), car il doit avoir les moyens de gérer un double décryptage. Encore un autre inconvénient des méthodes connues est qu'il faut aussi que le dispositif source contienne des moyens de gérer un double encryptage. Il n'est donc pas possible d'utiliser un dispositif source quelconque disponible dans le marché et assurer la diffusion à caractère privé du contenu. 30 3. OBJECTIFS DE L'INVENTION 2907287 3 L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique. Plus précisément, l'un des objectifs de la présente invention, dans au moins un mode de réalisation, est de fournir une technique de transmission sécurisée d'un contenu 5 entre un dispositif source et un dispositif destinataire, permettant une restriction d'accès à ce contenu, sans pour autant que le dispositif destinataire ne dispose d'une interface permettant à l'utilisateur d'entrer une information servant à la détermination d'une clé, ou la clé elle-même, et n'ait à gérer un double décryptage. L'invention a également pour objectif, dans au moins un mode de réalisation, de 10 fournir une telle technique de transmission sécurisée d'un contenu entre un dispositif source et un dispositif destinataire, permettant une restriction d'accès à ce contenu, sans pour autant que le dispositif source ne dispose d'une interface permettant à l'utilisateur d'entrer une information servant à la détermination d'une clé, ou la clé elle-même, et n'ait à gérer un double encryptage. 15 Un autre objectif de l'invention, dans au moins un mode de réalisation, est de fournir une telle technique qui soit simple à mettre en oeuvre et peu coûteuse. 4. EXPOSÉ DE L'INVENTION Dans un premier mode de réalisation particulier de l'invention, côté source, il est proposé un procédé de transmission sécurisée d'un contenu privé entre un dispositif 20 source et au moins un dispositif destination à travers un noeud source auquel le dispositif source est connecté et au moins un noeud destination auquel ledit au moins dispositif destination est connecté, lesdits dispositif source et noeud source utilisant un protocole de protection de contenu possédant une phase d'échange de paramètres de clé et une phase de transmission de contenu crypté avec la clé associée aux paramètres de clé 25 échangés. Ce procédé comprend les étapes suivantes : - réception par le noeud source de paramètres associés à une première clé pendant ladite phase d'échange de paramètres de clé entre le dispositif source et le noeud source ; - réception par le noeud source du contenu crypté avec ladite première clé pendant 30 ladite phase de transmission entre le dispositif source et le noeud source ; 2907287 4 - transmission par le noeud source du contenu crypté au moins avec la première clé audit au moins un noeud destination ; et - association d'un mot de passe au contenu privé, permettant de conditionner l'accès par ledit au moins un noeud destination aux paramètres de clé associés à 5 la première clé. Il est important de noter que dans ce premier mode de réalisation, le noeud source ne décrypte pas le contenu crypté avec la première clé, qui provient du dispositif source, avant de le transmettre au(x) noeud(s) destination. Par ailleurs, un mot de passe est associé au contenu privé. Comme expliqué par la suite, ce mot de passe est fourni à 10 au moins une entité tierce. Par entité tierce, on entend par exemple un utilisateur ou un noeud contrôleur. Ce premier mode de réalisation est transparent pour le dispositif source. Ainsi, et comme expliqué ci-après, sous réserve d'obtention préalable de ce mot de passe (par le noeud destination ou le noeud contrôleur), les paramètres de la première 15 clé sont ensuite déterminés par le noeud destination qui, côté destination, les transmet au dispositif destination lors de la phase d'échange de paramètres de clé du protocole de protection de contenu. En outre, ce noeud destination reçoit le contenu crypté avec la première clé puis le transmet au dispositif destination lors de la phase de transmission de contenu crypté du protocole de protection de contenu. 20 Ceci permet de garantir que le contenu reste crypté avec la première clé depuis le dispositif source jusqu'au dispositif destination (donc de bout en bout), sans pour autant que le dispositif destination ne dispose d'une interface permettant à un utilisateur d'entrer une information servant à la détermination de la première clé, ou la première clé elle-même, et n'ait à gérer un double décryptage. En d'autres termes, il est possible de 25 gérer le caractère privé d'un contenu, seule la fourniture des paramètres de la première clé (par exemple par un utilisateur, sous la forme d'un mot de passe) permettant d'accéder au contenu en clair. Dans un premier exemple du premier mode de réalisation, l'étape d'association d'un mot de passe au contenu privé est effectuée par un noeud contrôleur en charge 30 d'établir une connexion entre le dispositif source et le dispositif destination pour la 2907287 5 transmission du contenu privé, ladite étape d'association d'un mot de passe au contenu privé comprenant les étapes suivantes : réception des paramètres associés à la première clé et transmis par le noeud source ; 5 - échange, à travers une interface utilisateur du noeud contrôleur, du mot de passe avec un utilisateur, le mot de passe étant défini par le noeud contrôleur ou l'utilisateur ; - stockage du mot de passe dans une table d'association comprenant un identifiant dudit contenu, ledit mot de passe et les paramètres de clé associés à la première 10 clé. Ainsi, pour au moins un noeud destination donné (par exemple s'il est impliqué dans une connexion supplémentaire), la fourniture ultérieure au noeud contrôleur du mot de passe par l'utilisateur autorise le noeud contrôleur à transmettre audit au moins un noeud destination donné les paramètres de clé associés à la première clé. 15 Avantageusement, le mot de passe est défini par le contrôleur et ledit mot de passe est obtenu en utilisant les paramètres de clé associés à la première clé. Dans un deuxième exemple du premier mode de réalisation, l'étape d'association d'un mot de passe au contenu privé est effectuée par le noeud source et comprend les étapes suivantes: 20 - génération du mot de passe en utilisant les paramètres de clé associés à la première clé ; et - fourniture du mot de passe à un utilisateur, à travers une interface utilisateur du noeud source. Ainsi, la fourniture ultérieure du mot de passe à un noeud destination donné par 25 l'utilisateur permet audit noeud destination donné de retrouver les paramètres de clé associés à la première clé. Dans un troisième exemple du premier mode de réalisation, l'étape d'association d'un mot de passe au contenu privé est effectuée par le noeud source et comprend les étapes suivantes : 30 - génération du mot de passe en utilisant les paramètres de clé associés à la première clé ; et 2907287 6 - fourniture du mot de passe à un noeud contrôleur en charge d'établir une connexion entre le dispositif source et le dispositif destination pour la transmission du contenu privé. Le procédé comprend en outre l'étape suivante, effectuée par le noeud 5 contrôleur : fourniture, à travers une interface utilisateur du noeud contrôleur, du mot de passe à un utilisateur. Ainsi, pour au moins un noeud destination donné (par exemple s'il est impliqué dans une connexion supplémentaire), la fourniture ultérieure au noeud contrôleur du mot de passe par l'utilisateur autorise le noeud contrôleur à transmettre le mot de passe audit 10 au moins un noeud destination donné et ainsi permet audit au moins un noeud destination donné de retrouver les paramètres de clé associés à la première clé. Avantageusement, ledit mot de passe est le résultat d'une fonction bijective appliquée aux paramètres de clé associés à la première clé. Dans un quatrième exemple du premier mode de réalisation, l'étape 15 d'association d'un mot de passe au contenu privé est effectuée par le noeud source et comprend les étapes suivantes : -génération du mot de passe en utilisant les paramètres de clé associés à la première clé ; - fourniture du mot de passe à un noeud contrôleur en charge d'établir une 20 connexion entre le dispositif source et le dispositif destination pour la transmission du contenu privé. Le procédé comprend en outre les étapes suivantes, effectuées par le noeud contrôleur : - échange, à travers une interface utilisateur du noeud contrôleur, d'un second mot 25 de passe avec un utilisateur, ledit second mot de passe étant défini par le noeud contrôleur ou l'utilisateur ; - stockage dudit second mot de passe dans une table d'association comprenant un identifiant dudit contenu, ledit mot de passe et ledit second mot de passe. Ainsi, pour au moins un noeud destination donné (par exemple s'il est impliqué 30 dans une connexion supplémentaire), la fourniture ultérieure au noeud contrôleur dudit autre mot de passe par l'utilisateur autorise le noeud contrôleur à transmettre audit au 2907287 7 moins un noeud destination donné ledit mot de passe, et ainsi permet audit au moins un noeud destination donné de retrouver les paramètres de clé associés à la première clé. De façon avantageuse, le procédé comprend en outre les étapes suivantes : - cryptage avec une seconde clé, par le noeud source, du contenu crypté avec la 5 première clé, afin d'obtenir un contenu doublement crypté ; - transmission par le noeud source de paramètres associés à la seconde clé, pendant une phase d'échange de paramètres de clé entre le noeud source et ledit au moins un noeud destination ; et -transmission du contenu doublement crypté, pendant l'étape de transmission par 10 le noeud source du contenu crypté au moins avec la première clé. Dans un second mode de réalisation particulier de l'invention, côté destination, il est proposé un procédé de réception sécurisée d'un contenu privé par au moins un dispositif destination à travers au moins un noeud destination auquel ledit au moins dispositif destination est connecté, lesdits dispositif destination et noeud destination 15 utilisant un protocole de protection de contenu possédant une phase d'échange de paramètres de clé et une phase de transmission de contenu crypté avec la clé associée aux paramètres de clé échangés. Ce procédé comprend les étapes suivantes : - réception par ledit au moins un noeud destination du contenu privé, préalablement crypté avec une première clé et provenant d'un dispositif source à 20 travers un noeud source auquel ledit dispositif source est connecté ; - obtention d'un mot de passe associé au contenu privé ; - détermination des paramètres de clé associés à ladite première clé, par l'utilisation du mot de passe obtenu dans l'étape d'obtention ; - transmission par ledit au moins un noeud destination desdits paramètres de clé au 25 dispositif destination pendant ladite phase d'échange de paramètres de clé entre le noeud destination et le dispositif destination ; et - transmission du contenu crypté avec la première clé reçu à l'étape de réception au dispositif destination . Il est important de noter que le noeud destination n'a pas un fonctionnement 30 habituel puisque, dans sa communication avec le dispositif destination, selon le protocole de protection de contenu : 2907287 8 - dans la phase d'échange de clé, il transmet au dispositif destination les paramètres de la première clé, et non pas les paramètres d'une clé spécifique à cette communication avec le dispositif destination ; - avant la phase de transmission de contenu crypté, il ne crypte pas le contenu 5 (déjà crypté avec la première clé) avec une clé spécifique à cette communication avec le dispositif destination. Cette technique selon l'invention est donc mise en oeuvre de façon transparente pour le dispositif destination. En effet, le dispositif destination se comporte comme s'il communiquait de façon habituelle, selon le protocole de protection de contenu (par 10 exemple DTCP), avec un dispositif source. Or, en réalité, le noeud destination n'est pas le dispositif source (le dispositif source est celui qui effectue le premier cryptage, avec la première clé). Ainsi, et comme déjà indiqué ci-dessus, ceci permet de garantir que le contenu reste crypté avec la première clé depuis le dispositif source jusqu'au dispositif 15 destination (donc de bout en bout), sans pour autant que le dispositif destination ne dispose d'une interface permettant à un utilisateur d'entrer une information servant à la détermination de la première clé, ou la première clé elle-même, et n'ait à gérer un double décryptage. Dans un premier exemple du second mode de réalisation, l'étape d'obtention 20 d'un mot de passe et l'étape de détermination des paramètres de clé associés à ladite première clé sont effectuées par ledit au moins un noeud destination. L'étape d'obtention d'un mot de passe est effectuée par la saisie dudit mot de passe par un utilisateur, à travers une interface utilisateur dudit au moins un noeud destination. Dans un deuxième exemple du second mode de réalisation, l'étape d'obtention 25 d'un mot de passe et l'étape de détermination des paramètres de clé associés à ladite première clé sont effectuées par un noeud contrôleur en charge d'établir une connexion entre le dispositif source et le dispositif destination pour la réception du contenu privé. L'étape d'obtention d'un mot de passe est effectuée par la saisie dudit mot de passe par un utilisateur, à travers une interface utilisateur dudit noeud contrôleur. L'étape de 30 détermination des paramètres de clé est effectuée par la lecture, à partir du mot de passe obtenu à l'étape d'obtention, d'une table d'association comprenant un identifiant dudit 2907287 9 contenu, ledit mot de passe et les paramètres de clé associés à la première clé. Le procédé comprend en outre une étape de transmission audit au moins un noeud destination, par le noeud contrôleur, des paramètres déterminés à l'étape de détermination. 5 Dans un troisième exemple du second mode de réalisation, l'étape d'obtention d'un mot de passe est effectuée par un noeud contrôleur en charge d'établir une connexion entre le dispositif source et le dispositif destination pour la réception du contenu privé, ladite étape d'obtention d'un mot de passe étant effectuée par la saisie dudit mot de passe par un utilisateur, à travers une interface utilisateur dudit noeud 10 contrôleur. Le procédé comprend en outre une étape de transmission audit au moins un noeud destination, par le noeud contrôleur, du mot de passe obtenu à l'étape d'obtention. L'étape de détermination des paramètres de clé est effectuée par ledit au moins un noeud destination à partir du mot de passe transmis par le noeud contrôleur.Selon une caractéristique avantageuse, le mot de passe obtenu à l'étape d'obtention est le résultat 15 d'une fonction bijective appliquée aux paramètres de clé associés à la première clé et en ce que l'étape de détermination des paramètres de clé associés à la première clé est effectuée par application de la fonction inverse de la fonction bijective audit mot de passe. Dans un quatrième exemple du second mode de réalisation, l'étape d'obtention 20 d'un mot de passe est effectuée par un noeud contrôleur en charge d'établir une connexion entre le dispositif source et le dispositif destination pour la réception du contenu privé, ladite étape d'obtention d'un mot de passe comprenant les étapes suivantes : - obtention d'un second mot de passe par la saisie dudit second mot de passe par 25 un utilisateur, à travers une interface utilisateur dudit noeud contrôleur ; - détermination dudit mot de passe par la lecture, à partir dudit second mot de passe, d'une table d'association comprenant un identifiant dudit contenu, ledit mot de passe et ledit second mot de passe. En outre, le procédé comprend en outre une étape de transmission audit au moins 30 un noeud destination, par le noeud contrôleur, du mot de passe obtenu à l'étape de détermination dudit mot de passe. L'étape de détermination des paramètres de clé est 2907287 10 effectuée par ledit au moins un noeud destination à partir du mot de passe transmis par le noeud contrôleur. Avantageusement, le contenu reçu par le noeud destination est doublement crypté avec la première clé et une seconde clé et le procédé comprend en outre les étapes 5 suivantes : - une étape d'authentification et d'échange de paramètres de clé associés à la seconde clé entre le noeud source et le noeud destination ; et -décryptage, avec la seconde clé, du contenu doublement crypté, afin d'obtenir le contenu crypté uniquement avec la première clé. 10 Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur. Ce produit programme d'ordinateur comprend des instructions de code de programme pour l'exécution des étapes du procédé de transmission sécurisée précité et/ou du procédé de réception 15 sécurisée précité, lorsque ledit programme est exécuté sur un ordinateur. Dans un autre mode de réalisation, l'invention concerne un moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé de transmission sécurisée précité et/ou le procédé de réception sécurisée précité. 20 Dans un autre mode de réalisation, l'invention concerne un noeud source pouvant participer à la transmission sécurisée d'un contenu privé entre un dispositif source et au moins un dispositif destination à travers ledit noeud source auquel le dispositif source est connecté et au moins un noeud destination auquel ledit au moins dispositif destination est connecté, lesdits dispositif source et noeud source utilisant un protocole de protection de 25 contenu possédant une phase d'échange de paramètres de clé et une phase de transmission de contenu crypté avec la clé associée aux paramètres de clé échangés. Ce noeud source comprend : - des moyens de réception de paramètres associés à une première clé pendant ladite phase d'échange de paramètres de clé entre le dispositif source et le noeud 30 source ; 2907287 11 - des moyens de réception du contenu crypté avec ladite première clé pendant ladite phase de transmission entre le dispositif source et le noeud source ; - des moyens de transmission du contenu crypté au moins avec la première clé audit au moins un noeud destination, 5 un mot de passe étant associé au contenu privé, permettant de conditionner l'accès par ledit au moins un noeud destination aux paramètres de clé associés à la première clé. Dans un premier exemple de réalisation du noeud source, celui-ci comprend des moyens de transmission des paramètres associés à la première clé à un noeud contrôleur en charge d'établir une connexion entre le dispositif source et le dispositif destination 10 pour la transmission du contenu privé, afin que ledit noeud contrôleur effectue l'association d'un mot de passe au contenu privé. Avantageusement, pour effectuer l'association d'un mot de passe au contenu privé, le noeud source comprend : - des moyens de génération du mot de passe en utilisant les paramètres de clé 15 associés à la première clé ; et - des moyens de fourniture du mot de passe à un utilisateur, à travers une interface utilisateur du noeud source. Dans un deuxième exemple de réalisation du noeud source, celui-ci comprend, pour effectuer l'association d'un mot de passe au contenu privé : 20 - des moyens de génération du mot de passe en utilisant les paramètres de clé associés à la première clé ; et - des moyens de fourniture du mot de passe à un noeud contrôleur en charge d'établir une connexion entre le dispositif source et le dispositif destination pour la transmission du contenu privé, afin que le noeud contrôleur fournisse, à travers 25 une interface utilisateur du noeud contrôleur, le mot de passe à un utilisateur. Avantageusement, ledit mot de passe est le résultat d'une fonction bijective appliquée aux paramètres de clé associés à la première clé. Dans un troisième exemple de réalisation du noeud source, celui-ci comprend, pour effectuer l'association d'un mot de passe au contenu privé : 30 - des moyens de génération du mot de passe en utilisant les paramètres de clé associés à la première clé ; 2907287 12 - des moyens de fourniture du mot de passe à un noeud contrôleur en charge d'établir une connexion entre le dispositif source et le dispositif destination pour la transmission du contenu privé, afin que le noeud contrôleur : * échange, à travers une interface utilisateur du noeud contrôleur, un second 5 mot de passe avec un utilisateur, ledit second mot de passe étant défini par le noeud contrôleur ou l'utilisateur ; * stocke ledit second mot de passe dans une table d'association comprenant un identifiant dudit contenu, ledit mot de passe et ledit second mot de passe. 10 Dans un quatrième exemple de réalisation du noeud source, celui-ci comprend : - des moyens de cryptage avec une seconde clé du contenu crypté avec la première clé, afin d'obtenir un contenu doublement crypté ; - des moyens de transmission de paramètres associés à la seconde clé, pendant une phase d'échange de paramètres de clé entre le noeud source et ledit au moins un 15 noeud destination. En outre., lesdits moyens de transmission du contenu crypté au moins avec la première clé transmettent ledit contenu doublement crypté. Dans un autre mode de réalisation, l'invention concerne un noeud destination pouvant participer à la réception sécurisée d'un contenu privé par au moins un dispositif 20 destination à travers au moins ledit noeud destination auquel ledit au moins dispositif destination est connecté, lesdits dispositif destination et noeud destination utilisant un protocole de protection de contenu possédant une phase d'échange de paramètres de clé et une phase de transmission de contenu crypté avec la clé associée aux paramètres de clé échangés. Ce noeud destination comprend : 25 - des moyens de réception du contenu privé, préalablement crypté avec une première clé et provenant d'un dispositif source à travers un noeud source auquel ledit dispositif source est connecté ; - des moyens de réception ou détermination des paramètres de clé associés à ladite première clé, lesdits paramètres de clé étant déterminés par l'utilisation d'un mot 30 de passe associé au contenu privé et préalablement obtenu ; 2907287 13 -des moyens de transmission desdits paramètres de clé au dispositif destination pendant ladite phase d'échange de paramètres de clé entre le noeud destination et le dispositif destination ; et - des moyens de transmission au dispositif destination du contenu crypté avec la 5 première clé reçu par les moyens de réception. Dans un premier exemple de réalisation du noeud destination, celui-ci comprend : - des moyens d'obtention dudit mot de passe, par la saisie dudit mot de passe par un utilisateur, à travers une interface utilisateur dudit au moins un noeud destination ; et 10 - des moyens de détermination des paramètres de clé associés à ladite première clé, à partir du mot de passe obtenu. Dans un deuxième exemple de réalisation du noeud destination, celui-ci comprend des moyens de réception des paramètres de clé associés à ladite première clé, lesdits paramètres de clé étant déterminés et transmis par un noeud contrôleur en charge 15 d'établir une connexion entre le dispositif source et le dispositif destination pour la réception du contenu privé. Dans un troisième exemple de réalisation du noeud destination, celui-ci comprend : - des moyens de réception dudit mot de passe obtenu par un noeudcontrôleur en 20 charge d'établir une connexion entre le dispositif source et le dispositif destination pour la réception du contenu privé ; et - des moyens de détermination des paramètres de clé associés à ladite première clé, à partir du mot de passe reçu. Avantageusement, le mot de passe obtenu est le résultat d'une fonction bijective 25 appliquée aux paramètres de clé associés à la première clé, et les moyens de détermination des paramètres de clé associés à la première clé appliquent la fonction inverse de la fonction bijective audit mot de passe. De façon avantageuse, le contenu reçu par le noeud destination est doublement crypté avec la première clé et une seconde clé et le noeud destination comprend : 30 - des moyens d'authentification et d'échange de paramètres de clé associés à la seconde clé, entre le noeud source et le noeud destination ; et 2907287 14 - des moyens de décryptage, avec la seconde clé, du contenu doublement crypté, afin d'obtenir le contenu crypté uniquement avec la première clé. 5. LISTE DES FIGURES, D'autres caractéristiques et avantages de modes de réalisation de l'invention 5 apparaîtront à la lecture de la description suivante d'un mode de réalisation préférentiel de l'invention, donné à titre d'exemple indicatif et non limitatif (tous les modes de réalisation de l'invention ne sont pas limités aux caractéristiques et avantages de ce mode de réalisation préférentiel), et des dessins annexés, dans lesquels : la figure 1 présente le schéma d'un exemple de réseau audio-vidéo domestique 10 dans lequel peut être mise en oeuvre l'invention ; la figure 2 présente un organigramme du protocole DTCP lors de la transmission d'un contenu entre un dispositif source et un dispositif récepteur ; la figure 3 présente le schéma bloc d'un noeud du réseau domestique de la figure 1, selon un mode de réalisation particulier de l'invention ; 15 la figure 4 présente un organigramme d'un mode de réalisation particulier d'un procédé selon l'invention de transmission sécurisée d'un contenu, depuis un terminal source vers un réseau fédérateur, dans le contexte de la figure 1 ; la figure 5 présente un organigramme d'un mode de réalisation particulier d'un procédé selon l'invention de transmission sécurisée d'un contenu, depuis le 20 réseau fédérateur vers un terminal destinataire, dans le contexte de la figure 1 ; la figure 6 présente un organigramme d'un mode de réalisation particulier d'un procédé selon l'invention de transmission sécurisée d'un contenu, tel que mis en oeuvre dans un noeud contrôleur ; et la figure 7 présente un organigramme d'un mode de réalisation particulier d'un 25 procédé selon l'invention d'une seconde transmission sécurisée d'un contenu, tel que mis en oeuvre dans un noeud contrôleur. 6. DESCRIPTION DÉTAILLÉE On considère dans la suite que le protocole de protection de contenus mis en oeuvre est le protocole DTCP précité. Cependant, il est évident que l'invention 30 s'applique également à tout protocole de protection de contenus comprenant une phase d'échange de clé de cryptage et une phase de transmission de contenu crypté. 2907287 15 On se place dans la suite de la description, dans le cadre du réseau domestique audio-vidéo 1000 de la figure 1. Il est clair cependant que l'invention peut être mise en oeuvre dans tout réseau de communication. Le réseau domestique 1000 comprend un réseau fédérateur 106 comprenant lui- 5 même des noeuds 101, 102, 104, 112 interconnectés entre eux par des liens numériques. Les noeuds 101, 102, 104, 112 peuvent être également appelés points d'accès au réseau (ou Network Access Point ), et de ce fait sont désignés dans la suite par NAPO, NAP1, NAP2 et NAP3 respectivement. Aux noeuds sont reliés des équipements audio-vidéo 100, 103, 105, 110 à travers des liens numériques 107, 108, 109, 111, qui 10 peuvent être complémentés par des liens analogiques (non représentés), tel que décrit dans le document de référence sur la norme CEA-775 intitulé DTV 1394 Interface Specification , afin par exemple de permettre l'affichage d'informations graphiques ou d'interface homme-machine sur les téléviseurs 105 et 110, ces informations graphiques pouvant provenir soit des équipements audio-vidéo 100 et 103 soit des noeuds 101, 102, 15 104, 112 du réseau domestique 1000. Les liens numériques qui interconnectent les noeuds entre eux ou les équipements aux noeuds peut être conformes à titre d'exemple non limitatif au standard IEEE 1394 (décrit dans les documents IEEE Std. 1394-1995, Standard for High Performance Serial Bus , IEEE Std 1394a-2000, Standard for High Performance Serial Bus (Supplement) et IEEE P1394.1 Draft 0.15, Standard for 20 High Performance Serial Bus Bridges ), au standard Ethernet IEEE 802.3, ou au standard de communication radio IEEE 802.11. Dans l'exemple illustré par la figure 1, on suppose que : - un boîtier décodeur (ou STB, pour Set Top Box en anglais) 100, utilisé comme terminal source, est connecté au noeud NAPO 101, via un bus IEEE 1394 25 référencé 107 ; - un téléviseur numérique (ou DTV, pour Digital TV en anglais) 105, utilisé comme terminal destinataire, est connecté au noeud NAP2 104, via un bus IEEE 1394 référencé 109 ; 2907287 16 - un téléviseur numérique (ou DTV, pour Digital TV en anglais) 110, utilisé comme second terminal destinataire, est connecté au noeud NAP3 112, via un bus IEEE, 1394 référencé 111 ; - un lecteur de disque dur numérique audio-vidéo (ou HDD, pour Hard Disk 5 Drive en anglais) 103, utilisé comme dispositif de stockage, est connecté au noeud NAP1 102, via un bus IEEE 1394 référencé 108. Dans la suite de la description, on utilise à titre explicatif le premier exemple suivant de fonctionnement en deux temps : - tout d'abord (phase décrite ci-après en relation avec la figure 4), un utilisateur 10 souhaite qu'un contenu reçu par le boîtier décodeur 100 soit transmis et stocké de façon sécurisée dans le lecteur de disque dur numérique 103 ; - puis (phase décrite ci-après en relation avec la figure 5), cet utilisateur souhaite que le contenu stocké par le lecteur de disque dur numérique 103 soit transmis de façon sécurisée au téléviseur numérique 105. 15 Il est clair que la présente invention s'applique aussi si le terminal source et le terminal destinataire sont connectés à un même noeud (en d'autres termes, le noeud source et le noeud destinataire peuvent être confondus). Par exemple, en reprenant et modifiant l'exemple précédent, le boîtier décodeur STB 100 et le téléviseur numérique DTV 105 pourraient être connectés au même noeud (par exemple NAPO). 20 Dans la suite de la description, on utilise aussi à titre explicatif un second exemple de fonctionnement dans le cas d'une transmission sans stockage intermédiaire (par exemple sous la forme d'une lecture en temps réel, aussi appelée streaming en anglais) où un utilisateur souhaite qu'un contenu reçu par le boîtier décodeur STB 100 soit directement transmis de façon sécurisée au téléviseur numérique DTV 105. 25 Les procédés de transmission sécurisée de contenu selon l'invention sont par exemple mis en oeuvre sous la forme d'un logiciel et/ou d'une pluralité de sous logiciels (comprenant une pluralité d'algorithmes, par exemple ceux décrits ci-après en relation avec les figures 4 et 5) qui est (sont) exécuté(s) dans plusieurs noeuds du réseau 1000. On présente maintenant, en relation avec la figure 2, la mise en oeuvre du 30 protocole DTCP lors de la transmission d'un contenu entre un dispositif source, 10 15 20 25 30 2907287 17 référencé A (par exemple le boîtier décodeur STB 100), et un dispositif récepteur, référencé B (par exemple le noeud source NAPO 101). Le protocole DTCP classique comprend une phase 200 d'authentification mutuelle du dispositif récepteur B et du dispositif source A, suivi d'une phase 210 5 d'échange de clés entre ces deux dispositifs A et B et de cryptage/décryptage du contenu. La phase 200 d'authentification comprend les étapes suivantes : dans une première étape 201, le dispositif récepteur B émet une requête d'authentification, comprenant des informations d'authentification du dispositif récepteur B, qu'il envoie au dispositif source A ; dans une seconde étape 202, le dispositif source A vérifie les informations d'authentification du dispositif récepteur B ; dans une troisième étape 203, le dispositif source A envoie au dispositif récepteur B un message de réponse à la requête d'authentification précitée, comprenant des informations d'authentification du dispositif source A ; dans une quatrième étape 204, le dispositif récepteur B vérifie les informations d'authentification du dispositif source A ; dans une cinquième étape 205, le dispositif source A envoie au dispositif récepteur B un premier message signé comprenant des informations spécifiques au protocole DTCP ; dans une sixième étape 206, le dispositif récepteur B contrôle le premier message signé du dispositif source A et calcule une première clé d'authentification (Kauth) ; dans une septième étape 207, le dispositif récepteur B envoie à son tour, au dispositif source A, un second message signé comprenant des informations spécifiques au protocole DTCP ; dans une huitième étape 208, le dispositif source A contrôle le second message signé du dispositif récepteur B et calcule une seconde clé d'authentification (Kauth'). 2907287 18 La phase 210 d'échange de clés et de cryptage/décryptage du contenu comprend les étapes suivantes : dans une neuvième étape 211, le dispositif source A génère une information aléatoire, par exemple un nombre aléatoire Nc, calcule une 5 clé d'échange Kx et calcule une clé de cryptage Kc qui est fonction notamment du nombre aléatoire Nc et qui vérifie Kc =J[Kx, EMI, Nc], où J est une fonction déterminée, Kx la clé d'échange et EMI un paramètre classique du protocole DTCP ; dans une dixième étape 212, le nombre aléatoire Nc et la clé d'échange 10 Kx sont envoyés de façon sécurisée (c'est-à-dire sous forme cryptée) par le dispositif source A au dispositif récepteur B ; dans une onzième étape 213, le dispositif récepteur B calcule la clé de cryptage Kc au moyen du nombre aléatoire Nc et de la clé d'échange Kx ; dans une douzième étape 214, le dispositif source A crypte le contenu 15 avec la clé de cryptage Kc (en appliquant une fonction fKc), de manière à obtenir un contenu crypté noté Msa ; dans une treizième étape 215, le dispositif source A envoie le contenu crypté Msa au dispositif récepteur B ; dans une quatorzième étape 216, le dispositif récepteur B décrypte le 20 contenu crypté Msa au moyen de la clé de cryptage Kc (en appliquant une fonction f-'Kc qui est la fonction réciproque de la fonction fKc). On présente, en relation avec la figure 3, un mode de réalisation particulier d'un noeud 300 compatible avec les procédés de transmission sécurisé de l'invention. Ce noeud générique 300 correspond à l'un quelconque des noeuds NAPO 101, 25 NAP1 102, NAP2 104 et NAP3 112 de la figure 1, si l'on considère que chacun de ces noeuds peut jouer selon les cas, le rôle d'un noeud source ou un noeud destinataire. Il est clair cependant que certains noeuds peuvent être spécialisés et ne jouer que certain(s) de ces rôles. Le noeud 300 est connecté à la fois au réseau fédérateur 106, via un ou plusieurs 30 liens Ethernet 314, et à un ou plusieurs terminaux (par exemple un boîtier décodeur 2907287 19 STB, un téléviseur numérique DTV ou un lecteur de disque dur numérique HDD), via un bus numérique 313 (lien IEEE 1394). Le noeud 300 comprend : - un premier module d'interface 301 avec le bus numérique 313 ; 5 - un second module d'interface 312 avec le(s) lien(s) Ethernet 314 ; - un premier module FIFO ( First In First Out en anglais, ou premier entré premier sorti en français) d'émission/réception 302, relié au premier module d'interface 301 ; - un second module FIFO d'émission/réception 315, relié au second module 10 d'interface 312 ; - un premier module 304 d'encryptage/décryptage mettant en oeuvre des algorithmes d'encryptage et décryptage conformes au protocole DTCP, et placé entre le module FIFO d'émission/réception 302 et le module FIFO d'émission/réception 305 ; 15 - un second module 311 d'encryptage/décryptage mettant en oeuvre des algorithmes d'encryptage et décryptage conformes au protocole DTCP, et placé entre le module FIFO d'émission/réception 305 et le module FIFO d'émission/réception 315 ; - un troisième module FIFO d'émission/réception 305, relié au premier 304 et second 311 modules d'encryptage/décryptage ; - un module de gestion de FIFO 303, permettant de contrôler les accès (en lecture et en écriture) aux modules FIFO 302, 305 et 315, conformément aux requêtes d'un module gestionnaire de pont 306 ; - un module de contrôle DTCP 307, implémentant le protocole DTCP et relié aux premier 304 et second 311 modules de cryptage/décryptage, permettant l'activation et/ou la désactivation des moyens d'encryptage/décryptage des premier 304 et second 311 modules pour un flux donné transitant entre l'interface 301 et l'interface 312 ; - un microprocesseur 109 (ou CPU, pour Central Processing Unit en anglais) ; 20 25 2907287 20 - un bloc mémoire 110 (ou EPROM, pour Erasable Programmable Read Only Memory en anglais), relié au microprocesseur 109 ; - un troisième module d'interface 308 avec le microprocesseur 109, relié au module de contrôle DTCP 307 et au module gestionnaire de pont 306. 5 On présente maintenant, en relation avec l'organigramme de la figure 4, un mode de réalisation particulier d'un procédé selon l'invention de transmission sécurisée d'un contenu, depuis un terminal source vers le réseau fédérateur, dans le contexte de la figure 1. On rappelle que dans l'exemple illustratif considéré, on suppose que l'utilisateur 10 souhaite qu'un contenu reçu par le boîtier décodeur STB 100 (terminal source) soit transmis et stocké de façon sécurisée dans le lecteur de disque dur numérique HDD 103 (dispositif de stockage), via les noeuds NAPO 101 (noeud source) et NAP1 102 (noeud destinataire). Dans une étape référencée 401, le noeud source NAPO reçoit une requête d'un 15 contrôleur demandant la transmission et le stockage d'un contenu privé (c'est-à-dire un flux privé) depuis le boîtier décodeur STB 100 vers le lecteur de disque dur numérique HDD 103. En précisant que le contenu est privé, le contrôleur indique au noeud source NAPO qu'il doit mettre en oeuvre le procédé selon l'invention, assurant une transmission sécurisée de bout en bout de ce contenu (pas seulement entre noeuds, mais aussi jusqu'à 20 la réception par le terminal destinataire, c'est-à-dire le téléviseur numérique DTV 105 dans l'exemple considéré, voir figure 5). Les étapes mises en oeuvre par le contrôleur, qui est un noeud du réseau 1000 qui sert d'interface avec l'utilisateur, qui permet le contrôle des divers équipements du réseau et qui permet la mise en communication desdits équipements, seront expliquées ultérieurement en relation avec l'organigramme 25 de la figure 6. Dans une étape référencée 402, le noeud source NAPO détermine si le flux est déjà en cours, c'est-à-dire si la connexion de flux est déjà établie entre le terminal source STB 100 et le noeud NAPO 101. Il est à noter que si une connexion est déjà établie, elle est considérée comme n'étant pas privée au sens de l'invention et donc le contenu est 30 décrypté par le noeud NAPO. C'est pourquoi, lors d'une étape 405, le noeud NAPO 101 stoppe le décryptage du flux, afin de rendre privée la connexion avec le terminal source 2907287 21 STB 100, au sens de l'invention. A une étape 406, le noeud NAPO obtient les paramètres Kx et Nc qui servent à définir la clé de cryptage utilisée par le terminal source STB 100 pour la transmission sécurisée du contenu audio-vidéo sur le lien 107. Si à l'étape 402, il est déterminé que le flux n'est pas déjà en cours, le noeud 5 source NAPO lance un échange DTCP avec le boîtier décodeur STB 100, comprenant une phase d'authentification dans une étape référencée 403 et une phase d'échange de clé et de cryptage/décryptage dans une étape référencée 404 (voir la description ci-dessus de la figure 2). Au cours de cet échange, le boîtier décodeur STB transmet de façon sécurisée au noeud source NAPO les paramètres Nc et Kx. A partir de ces 10 paramètres, le noeud source NAPO peut calculer la première clé de cryptage Kc avec laquelle le boîtier décodeur STB 100 a encrypté le contenu crypté qu'il transmet au noeud source NAPO. Dans une étape référencée 407, le noeud source NAPO génère un mot de passe à partir des paramètres Nc et Kx, détermine, dans une étape référencée 408, une entité 15 tierce du réseau 1000 à qui ce mot de passe doit être fourni et fournit, dans une étape référencée 409, ce mot de passe à ladite entité tierce. Dans l'exemple traité ici, cette entité tierce est le contrôleur, tel que décrit ultérieurement en relation avec la figure 6. Plusieurs méthodes d'embrouillage ( scrambling en anglais), bien connues de l'homme du métier, peuvent être utilisées pour la génération du mot de passe à partir des 20 paramètres Nc et Kx, et notamment un mécanisme de type AES ( Advanced Encryption Standard ) qui est un bloc de codage symétrique capable de crypter et décrypter des informations. L'algorithme AES peut utiliser des clés cryptographiques de 128, 192 et 256 bits pour crypter et décrypter des données en blocs de 128 bits. Les paramètres Kx et Nc peuvent être utilisés en entrée de l'algorithme AES et le résultat 25 sera le mot de passe fourni à l'utilisateur. D'autres méthodes, bien connues de l'homme du métier, peuvent être utilisées pour la génération du mot de passe. Toute fonction bijective ou une combinaison de fonctions bijectives peut être utilisée, le but étant de pouvoir obtenir de manière déterministe le mot de passe à partir des paramètres Nc et Kx, et de pouvoir obtenir, en 30 utilisant la fonction inverse ou la combinaison de fonctions inverses (elle(s)-même bijective(s)), les paramètres Nc et Kx à partir du mot de passe. 2907287 22 Selon un autre mode de réalisation de l'invention (non représenté sur l'organigramme), le noeud source NAPO fournit directement les paramètres Nc et Kx à l'entité tierce (par exemple le contrôleur). L'entité tierce est ensuite chargée de ne fournir ces paramètres qu'aux noeuds destination reliés à des dispositifs destination 5 autorisés à recevoir le contenu privé en clair. L'entité tierce peut par exemple fournir les paramètres de clé aux noeuds destination sans conditions lorsque la connexion pour le transport du contenu est établie pour la première fois, et sous réserve d'un mot de passe lorsque des connexions supplémentaires sont demandées pour desservir de nouveaux dispositifs destination. Dans ce cas, l'entité tierce maintient une table de correspondance 10 pour chaque contenu qu'elle a en charge, comprenant un identifiant du contenu, les paramètres de clé Nc et Kx qui lui sont associés ainsi qu'un mot de passe pour conditionner la délivrance de ces paramètres de clé. Dans cet autre mode de réalisation, il n'est pas nécessaire d'avoir une fonction bijective entre le mot de passe et les paramètres de clé Nc et Kx. 15 Dans des étapes référencées 410 et 411, le noeud source NAPO 101 lance un échange DTCP avec le noeud destinataire NAP1 102, afin de s'échanger une seconde clé de cryptage Kc1, afin de sécuriser la transmission entre NAPO 101 et NAP1 102. Ces étapes ne sont évidemment pas nécessaires si le noeud source NAPO et le noeud destinataire NAP1 ont déjà établi une connexion sécurisée pour le transfert de ce 20 contenu, comme cela peut-être le cas quand, par exemple, il a été déterminé à l'étape 402 que la connexion était déjà établie mais considérée comme n'étant pas privée au sens de l'invention. Dans une étape référencée 412, après que toutes les connexions de flux ont été établies (d'une part entre le boîtier décodeur STB et le noeud source NAPO, et d'autre 25 part entre le noeud source NAPO et le noeud destinataire NAP1), le noeud source NAPO : - reçoit le contenu crypté avec la première clé Kc et provenant du boîtier décodeur STB 100; - ne décrypte pas le contenu crypté avec la première clé ; - encrypte avec la seconde clé le contenu déjà crypté avec la première clé, 30 obtenant ainsi un contenu doublement crypté ; puis lors d'un étape référencée 413 : 2907287 23 - transmet le contenu doublement crypté au noeud destinataire NAP1. Ainsi, le noeud destinataire NAP1 102 peut ensuite décrypter avec la seconde clé le contenu doublement crypté, obtenant le contenu crypté une seule fois avec la première clé Kc, puis transmettre le contenu crypté une seule fois au lecteur de disque 5 dur numérique HDD afin qu'il le stocke. Le contenu est donc stocké sous une forme cryptée avec la première clé Kc. Il est à noter que, par exemple, si le disque dur HDD 103 est relié au noeud NAP1 au moyen d'un lien 108 de type IEEE1394, le noeud destinataire NAP1 102 lance un échange DTCP avec le disque dur HDD 103, afin de s'échanger une troisième clé de cryptage Kc2, afin de sécuriser la transmission entre le 10 noeud destinataire NAP1 102 et le disque dur HDD 103. Le noeud destinataire NAP1 102 encrypte avec la troisième clé le contenu déjà crypté avec la première clé, obtenant ainsi un contenu, une fois encore, doublement crypté. Ainsi, le disque dur HDD 103 peut ensuite décrypter avec la troisième clé le contenu doublement crypté, obtenant le contenu crypté une seule fois avec la première clé Kc afin de le stocker. Le 15 contenu est donc, ici aussi, stocké sous une forme cryptée avec la première clé Kc. Cette mise en oeuvre apparaît dans les étapes 511 à 517 de la figure 5. On présente maintenant, en relation avec l'organigramme de la figure 5, un mode de réalisation particulier d'un procédé selon l'invention de transmission sécurisée d'un contenu, depuis le réseau fédérateur vers un terminal destinataire, dans le contexte 20 de la figure 1. On rappelle que dans l'exemple illustratif considéré, on suppose que l'utilisateur souhaite que le contenu stocké par le lecteur de disque dur numérique HDD 103 soit transmis de façon sécurisée au téléviseur numérique DTV 105, via les noeuds NAP1 102 (noeud de stockage) et NAP2 104 (noeud destinataire). 25 Dans une étape référencée 501, le noeud destinataire NAP2 104 reçoit une requête d'un contrôleur demandant la lecture et la transmission vers le téléviseur numérique DTV 105 d'un contenu préalablement stocké. Après réception de cette requête, le noeud destinataire NAP2 104 détecte dans une étape 502 si le contenu demandé est un contenu privé, par exemple en consultant une table résumant tous les 30 contenus privés actuellement stockés. Cette table peut être stockée sur l'un des noeuds (NAP2 104 par exemple) ou sur chaque noeud du réseau fédérateur. En cas de détection 2907287 24 positive, le noeud destinataire NAP2 104 sait qu'il doit mettre en oeuvre le procédé selon l'invention, assurant une transmission sécurisée de bout en bout de ce contenu (pas seulement entre noeuds, mais aussi jusqu'à la réception par le téléviseur numérique DTV 105). Si le contenu demandé n'est pas un contenu privé, le noeud NAP2 104 doit 5 procéder au transfert sécurisé (avec des quatrième et cinquième clés Kc3 et Kc4 respectivement) des données qu'il reçoit du noeud NAP1 et qu'il transmet vers le terminal destinataire, selon la méthode usuelle, telle que présentée dans les étapes 511 à 517 (déjà décrites ci-dessus dans le cas où le noeud NAP1 reçoit du noeud NAPO et transmet vers le terminal destinataire HDD, avec des troisième et seconde clés Kc2 et 10 Kcl respectivement). Si le contenu demandé est un contenu privé, dans une étape référencée 503, le noeud destinataire NAP2 104 obtient un mot de passe correspondant au contenu à transférer en vue de sa visualisation. Ce mot de passe est transmis par le contrôleur lors de l'étape 610, qui sera décrite ultérieurement en relation avec la figure 6. 15 Dans une étape référencée 504, le noeud destinataire NAP2 104 obtient les paramètres Nc et Kx de la première clé Kc, à partir du mot de passe fourni par l'utilisateur au contrôleur (étape 608 de la figure 6) puis par le contrôleur au noeud destinataire (étape 610 de la figure 6) (si ce mot de passe est le bon). Pour cela, le noeud destinataire NAP2 104 utilise une méthode de désembrouillage ( descrambling en 20 anglais) inverse celle utilisée à l'étape référencée 407 sur la figure 4). Dans une étape référencée 505, le noeud destinataire NAP2 104 utilise les paramètres Nc et: Kx de la première clé Kc lors d'un échange DTCP avec le téléviseur numérique DTV 105. Plus précisément, le noeud destinataire NAP2 104 ne génère pas de nouvelles valeurs pour les paramètres DTCP (nombre aléatoire et clé d'échange) mais 25 utilise, lors de la phase d'échange de clé avec le téléviseur numérique DTV 105, les paramètres Nc et Kx obtenus à l'étape précédente référencée 504. Ainsi, le téléviseur numérique DTV 105 peut calculer la première clé Kc. Dans des étapes référencées 506 et 507, le noeud destinataire NAP2 lance un échange DTCP avec le noeud source NAP1 102, afin de s'échanger une sixième clé de 30 cryptage Kc5. 2907287 25 Dans une étape référencée 508, après que toutes les connexions de flux ont été établies (d'une part entre le noeud source NAP1 102 et le noeud destinataire NAP2 104, et d'autre part entre le noeud destinataire NAP2 104 et le téléviseur numérique DTV 105), le noeud destinataire NAP2 104 reçoit un contenu doublement crypté (avec les 5 première et troisième clés, Kc et Kc5 respectivement) provenant du noeud source NAP1 102. Dans l'étape référencée 509, le noeud destinataire NAP2 104 décrypte avec la sixième clé le contenu doublement crypté avec les première et sixième clés, obtenant ainsi un contenu crypté une seule fois, avec la première clé Kc. 10 Dans une étape référencée 510, le noeud destinataire NAP2 104 ne crypte pas le contenu crypté avec la première clé (il l'est en effet déjà), et transmet le contenu crypté avec la première clé au téléviseur numérique DTV 105. Ainsi, le téléviseur numérique DTV 105 peut ensuite décrypter avec la première clé Kc le contenu crypté qu'il reçoit (voir l'étape référencée 505 pour l'obtention de la 15 première clé Kc par le téléviseur numérique DTV 105), obtenant le contenu non crypté. Si le mot de passe fourni par le contrôleur à l'étape 503 correspond au mot de passe construit à l'étape 407, les paramètres Nc et Kx obtenus à l'étape 504 sont ceux correspondant à la première clé Kc et le contenu est donc correctement affiché par le téléviseur numérique DTV 105. 20 Il est à noter que, si au moment où le noeud destinataire reçoit la requête pour une connexion de flux privé, le contenu est déjà en cours de transit jusqu'au terminal destinataire par le biais du noeud destinataire, mais de manière non privée, le noeud destinataire devra stopper les moyens d'encryptage du flux considéré, rompre la connexion courante, puis établir une nouvelle connexion sans réactiver les moyens 25 d'encryptage pour ce flux. En effet, même si le contenu à afficher est le même, la méthode de transport à travers le réseau change, comme indiqué à l'étape 402. La clé de cryptage correspondant au flux transporté de manière sécurisée entre le noeud destinataire et le terminal destinataire change : dans le premier cas, cette clé Kc3 correspond aux paramètres de clé Nc3 et Kx3 échangés entre le noeud destinataire et le 30 terminal destinataire, comme indiqué lors des étapes 511 et 512. Dans le deuxième cas, cette clé Kc correspondaux paramètres de clé Nc et Kx échangés entre le noeud source 2907287 26 et le terminal source, comme indiqué lors de l'étape 504. De plus, dans le premier cas, le noeud destinataire doit encrypter le flux pour le transmettre de manière sécurisée vers le terminal destinataire ; dans le second cas, le noeud destinataire ne doit pas encrypter le flux pour le transmettre de manière sécurisée vers le terminal destinataire, car celui-ci 5 est déjà crypté avec la clé Kc. Il est aussi à noter que la démarche inverse est appliquée dans le cas où une connexion passe d'un statut privé à un statut non privé, au sens de l'invention. Le noeud destinataire devra rompre la connexion courante, puis établir une nouvelle connexion avec de nouveaux paramètres de clé échangés avec le terminal destinataire et activer en 10 conséquence ses moyens d'encryptage pour ce flux. On présente maintenant, en relation avec l'organigramme de la figure 6, un mode de réalisation particulier d'un procédé selon l'invention de transmission sécurisée d'un contenu, depuis un terminal source vers un terminal destinataire, dans le contexte de la figure 1. 15 Lors d'une étape 601, le contrôleur reçoit une requête utilisateur pour une connexion de flux privée. Le contrôleur est préférentiellement un noeud du réseau 1000 qui fournit une interface à l'utilisateur lui permettant de mettre en communication des terminaux sources et destinataires, afin de visualiser, enregistrer,... des contenus audiovidéo. Chaque élément noeud ou terminal du réseau 1000 peut jouer le rôle de 20 contrôleur. On considèrera de manière préférentielle dans la suite de la description que tout noeud NAPO 101, NAP1 102, NAP2 104, NAP3 112 du réseau fédérateur jouera le rôle de contrôleur et servira d'interface avec l'utilisateur. A l'étape 602, le contrôleur détermine le noeud source, ainsi que le terminal source concernés par la requête. Dans l'exemple utilisé jusqu'ici, le noeud source est 25 NAPO 101 et le terminal source est le boîtier décodeur STB 100, dans le cas du stockage d'un contenu privé sur le disque dur HDD 103 ; le noeud source est NAP1 102 et le terminal source est le disque dur HDD 103, dans le cas de la relecture d'un contenu privé préalablement stocké sur le disque dur HDD 103. A l'étape 603, le contrôleur détermine si le terminal source est un dispositif de 30 stockage. Dans le cas d'une détermination positive, le contrôleur envoie une requête de connexion de flux simple. En effet, lorsque l'on se place dans le cas où un contenu privé 2907287 27 doit être relu du disque dur HDD 103, le contenu stocké est crypté avec la première clé Kc, tel que déjà décrit en relation avec la figure 4. Le traitement de ce flux est transparent pour le noeud destinataire NAP1. Il doit donc établir le transfert de manière sécurisée avec le terminal source, c'est-à-dire le disque dur HDD 103 et décrypter ledit 5 flux avec la clé déterminée lors de la phase d'échange DTCP avec le disque dur HDD 103. Il doit ensuite encrypter ce flux avec une autre clé déterminée lors de la phase d'échange DTCP avec le noeud destinataire NAP2 104. C'est donc la procédure usuelle qui est utilisée ici pour que le noeud destinataire NAP1 102 transfère le flux jusqu'au noeud destinataire NAP2 104. 10 Lors d'une étape 605, le contrôleur détermine le noeud destinataire, ainsi que le terminal destinataire concernés par la requête. Dans l'exemple utilisé jusqu'ici, le noeud destinataire est NAP2 104 et le terminal destinataire est le téléviseur numérique DTV 105, dans le cas de la relecture d'un contenu privé préalablement stocké sur le disque dur HDD 103. 15 A l'étape 606, le contrôleur détermine si le terminal destinataire est un dispositif de stockage. Si tel est le cas, la requête utilisateur consiste à faire une copie disque à disque du contenu. Le contrôleur envoie donc une requête de connexion de flux simple au noeud destinataire. Le contenu crypté avec la première clé Kc est alors transféré d'un disque à un autre en utilisant la manière usuelle. Le contenu sera ainsi toujours encrypté 20 avec la première clé Kc, bien qu'il ait été déplacé. Si, à l'étape 606, le contrôleur détermine que le terminal destinataire n'est pas un dispositif de stockage, la requête utilisateur consiste à visualiser le contenu privé préalablement stocké. Le contrôleur obtient alors à l'étape 608 un mot de passe devant correspondre au contenu à visualiser. Ceci peut être effectué, par exemple, en 25 demandant, via son interface homme-machine, à l'utilisateur de fournir le mot de passe qui lui a été préalablement communiqué (voir l'étape référencée 616 sur la figure 6) au moment de l'enregistrement du flux audio-vidéo sur le disque dur HDD 103. Le contrôleur indique alors au noeud destinataire, à l'étape 609, que la connexion est privée et qu'il doit mettre en oeuvre l'invention telle que décrite en relation avec la 30 figure 5. Il envoie ensuite, lors d'une étape référencée 610, le mot de passe obtenu à l'étape 608 au noeud destinataire, qui s'en servira pour déterminer les paramètres Kx et 2907287 28 Nc qu'il pourra fournir au terminal destinataire DTV 105 pour reconstruire la clé Kc et ainsi décrypter le contenu privé. Le contenu est donc ainsi correctement affiché par le téléviseur numérique DTV 105. Ainsi, si un autre utilisateur tente d'accéder à un contenu privé préalablement 5 stocké par le premier utilisateur sur le HDD 103 selon la méthode précédemment décrite, le noeud destinataire NAP3 112 reçoit, via son interface homme-machine (par exemple une interface graphique associée à un boîtier de télécommande), une requête demandant la lecture et la transmission vers le téléviseur numérique DTV 110 du contenu préalablement stocké. Ce second utilisateur ne disposant pas du mot de passe 10 déterminé à l'étape 407, c'est-à-dire au moment où le premier utilisateur a demandé de stocker le contenu de manière privée, les paramètres Nc et Kx corrects ne peuvent pas être obtenus, donc la première clé Kc ne peut pas être déterminée et le contenu ne peut donc pas être correctement affiché par le téléviseur numérique DTV 110. Si, à l'étape 603, le contrôleur détermine que le terminal source n'est pas un 15 dispositif de stockage, le contrôleur envoie, à l'étape 611, une requête de connexion de flux privé. En effet, lorsque l'on se place dans le cas où un contenu privé doit être stocké sur le disque dur HDD 103, le contenu doit être stocké crypté avec la première clé Kc, tel que déjà décrit en relation avec la figure 4. Le noeud source NAPO 101 doit donc mettre en oeuvre l'invention en ne décryptant pas le contenu transféré du boîtier 20 décodeur STB 100. Lors d'une étape 612, le contrôleur détermine le noeud destinataire, ainsi que le terminal destinataire concernés par la requête. Dans l'exemple utilisé jusqu'ici, le noeud destinataire est NAP1 102 et le terminal destinataire est le disque dur HDD 103, dans le cas du stockage d'un contenu privé sur le disque dur HDD 103. 25 A l'étape référencée 613, le contrôleur détermine si le terminal destinataire est un dispositif de stockage. Si tel est le cas, la requête utilisateur consiste à faire une copie à titre privé d'un contenu, comme c'est le cas dans l'exemple présenté jusqu'ici où le contenu issu du boîtier décodeur STB 100 doit être stocké sur le disque dur HDD 103. Alors, à l'étape 618, le contrôleur envoie au noeud destinataire une requête pour une 30 connexion de flux simple. En effet, lorsque l'on se place dans le cas où un contenu privé doit être stocké ;sur le disque dur HDD 103, le contenu doit être stocké crypté avec la 2907287 29 première clé Kc, tel que déjà décrit en relation avec la figure 4. Le traitement de ce flux est transparent pour le noeud destinataire NAP1. Il doit donc établir le transfert de manière sécurisée avec le terminal destinataire, c'est-à-dire le disque dur HDD 103 et encrypter ledit flux avec la clé déterminée lors de la phase d'échange DTCP avec le 5 disque dur HDD 103. C'est donc la procédure usuelle qui est utilisée ici pour que le noeud destinataire NAP1 102 transfère le flux jusqu'au terminal destinataire HDD 103. A l'étape référencée 619, le contrôleur reçoit le mot de passe associé au contenu privé, c'est-à-dire le mot de passe obtenu à partir des paramètres Nc et Kx qui permettent de définir la première clé Kc avec laquelle le contenu est crypté par le 10 dispositif source. Ce mot de passe est envoyé par le noeud source à l'étape référencée 409, tel qu'il a été décrit en relation avec la figure 4. Le contrôleur peut ensuite afficher le mot de passe à l'utilisateur au moyen de son interface graphique, lors d'une étape référencée 620. Ce mot de passe sera réutilisé à la relecture du contenu privé à partir du disque dur HDD 103, comme déjà décrit et indiqué à l'étape référencée 608. 15 L'utilisateur ayant fait la requête de stockage détient donc une information privée, qui est ledit mot de passe, qui lui permet de visualiser à partir de tout téléviseur numérique DTV 105, 110, le contenu ainsi stocké. Tout autre utilisateur, n'ayant pas connaissance dudit mot de passe, sera dans l'incapacité de visualiser un contenu privé stocké selon l'invention. 20 Afin d'expliquer les étapes référencées 614 à 617 de l'organigramme de la figure 6, on présente maintenant un mode de réalisation particulier d'un procédé selon l'invention de transmission sécurisée d'un contenu dans le cas d'une transmission sans stockage intermédiaire, dans le contexte de la figure 1. Dans l'exemple illustratif considéré, on suppose que l'utilisateur souhaite qu'un contenu reçu par le boîtier 25 décodeur STB 100 (terminal source) soit transmis de façon sécurisée via les noeuds NAPO 101 (noeud source) et NAP2 104 (noeud destinataire), jusqu'au téléviseur DTV 105 (terminal destinataire). Lors d'une étape référencée 601, le contrôleur reçoit une requête utilisateur pour une connexion de flux privée. A l'étape référencée 602, le contrôleur détermine le noeud 30 source, ainsi que le terminal source concernés par la requête. Dans l'exemple utilisé jusqu'ici, le noeud source est NAPO 101 et le terminal source est le boîtier décodeur 2907287 30 STB 100. A l'étape référencée 603, dans l'exemple considéré, le contrôleur détermine que le contenu privé n'est pas localisé sur un dispositif de stockage. Il envoie alors, à l'étape référencée 611, au noeud source NAPO 101 une requête de connexion de flux privée, afin que le noeud source NAPO 101 mette en oeuvre l'invention, comme présenté 5 à la figure 4. Lors d'une étape référencée 612, le contrôleur détermine le noeud destinataire, ainsi que le terminal destinataire concernés par la requête. Dans l'exemple considéré, le noeud destinataire est NAP2 104 et le terminal destinataire est le téléviseur DTV 105. A l'étape référencée 613, dans l'exemple considéré, le contrôleur détermine que le 10 terminal destinataire n'est pas un dispositif de stockage. Il envoie alors, à l'étape référencée 614, au noeud destinataire NAP2 104 une requête de connexion de flux privée, afin que le noeud source NAP2 104 mette en oeuvre l'invention, comme présenté à la figure 5. A l'étape référencée 615, le contrôleur reçoit le mot de passe associé au contenu 15 privé, c'est-à-dire le mot de passe obtenu à partir des paramètres Nc et Kx qui permettent de définir la première clé Kc avec laquelle le contenu est crypté par le dispositif source. Ce mot de passe est envoyé par le noeud source NAPO 101 à l'étape référencée 409, tel qu'il a été décrit en relation avec la figure 4. Le contrôleur peut ensuite afficher le mot de passe à l'utilisateur au moyen de son interface graphique, lors 20 d'une étape référencée 616. Ce mot de passe pourra ainsi être réutilisé par l'utilisateur, si celui-ci souhaite se déplacer à un autre point d'accès du réseau, par exemple pour visualiser le contenu privé sur le téléviseur DTV 110. Ce cas sera plus amplement décrit en relation avec la figure 7. Le contrôleur envoie ensuite, lors d'une étape référencée 617, le mot de passe reçu à l'étape référencée 615 au noeud destinataire, qui s'en servira 25 pour déterminer les paramètres Kx et Nc qu'il pourra fournir au terminal destinataire DTV 105 pour reconstruire la clé Kc et ainsi décrypter le contenu privé. Le contenu est donc ainsi correctement affiché par le téléviseur numérique DTV 105. Il apparaît ainsi que dans le cas où le contenu privé est visualisé sans stockage intermédiaire, l'utilisateur n'a pas besoin d'entrer le mot de passe dans la procédure. Le 30 mot de passe est directement envoyé par le contrôleur au noeud destinataire. L'utilisateur est simplement informé de ce mot de passe dans le cas où l'utilisateur déciderait 2907287 31 d'enregistrer, par exemple sur le disque dur HDD 103, le contenu privé en cours de visualisation. En effet, le noeud source NAPO 101 mettant déjà en oeuvre l'invention dans le cadre de la visualisation du contenu sur le téléviseur DTV 105, il suffira simplement d'établir une connexion de flux de manière usuelle avec le disque dur HDD 5 103 pour stocker ledit contenu de manière privée, au sens de l'invention. En utilisant le même mot de passe que celui utilisé pour la visualisation sur le téléviseur DTV 105, l'utilisateur pourra ainsi par la suite lancer une relecture dudit contenu privé stocké sur le disque dur HDD 103. On présente maintenant, en relation avec l'organigramme de la figure 7, un 10 mode de réalisation particulier d'un procédé selon l'invention de transmission sécurisée d'un contenu, depuis un terminal source vers un terminal destinataire, dans le contexte de la figure 1, ledit contenu étant déjà en cours de transfert au sein du réseau 1000. En effet, jusqu'ici il a été considéré, par souci de simplification de la description de l'invention, que la requête de connexion privée concernait un contenu privé stocké ou 15 un contenu non privé pour lequel l'utilisateur demandait un traitement privé, au sens de l'invention. Cependant, comme déjà mentionné, l'utilisateur peut vouloir stocker sur un disque un contenu privé déjà en cours de visualisation ou bien peut vouloir se déplacer à un autre point d'accès du réseau pour visualiser ce contenu. A l'étape référencée 701, le contrôleur reçoit une requête utilisateur pour une 20 connexion de flux privée, de la même manière que précédemment décrit. A l'étape référencée 702, le contrôleur détermine si la connexion de flux considérée est relative à un contenu privé, au sens de l'invention, déjà en cours de transmission au sein du réseau 1000. Si ce n'est pas le cas, l'organigramme renvoie à l'étape référencée 601 et le processus s'exécute comme précédemment décrit. 25 Si à l'étape référencée 702, il est déterminé que la connexion de flux considérée est relative à un contenu privé déjà en cours de transmission au sein du réseau 1000, lors d'une étape 704, le contrôleur détermine le noeud destinataire, ainsi que le terminal destinataire concernés par la requête. Dans le cas où un utilisateur souhaite accéder au contenu privé issu du boîtier décodeur STB 100 à partir du téléviseur DTV 110, ledit 30 contenu étant déjà visualisé sur le téléviseur DTV 105, le noeud destinataire est NAP3 112 et le terminal destinataire est le téléviseur DTV 110. Dans le cas où un 2907287 32 utilisateur souhaite stocker un contenu privé issu du boîtier décodeur STB 100 sur le disque dur HDD 103, ledit contenu étant déjà visualisé sur le téléviseur DTV 105, le noeud destinataire est NAP1 102 et le terminal destinataire est le disque dur HDD 103. A l'étape référencée 705, le contrôleur détermine si le terminal destinataire est 5 un dispositif de stockage. Si tel est le cas, la requête utilisateur consiste à faire une copie à titre privé d'un contenu. Comme déjà décrit précédemment, à l'étape 706, le contrôleur envoie au noeud destinataire une requête pour une connexion de flux simple. Un connexion s'établira alors du terminal source STB 100 jusqu'au terminal destinataire HDD 103 et le contenu sera stocké crypté avec la première clé Kc, utilisée par la source 10 pour le transfert du contenu de manière sécurisée sur le lien 107. Si à l'étape 705, le contrôleur détermine que le terminal destinataire n'est pas un dispositif de stockage, le contrôleur obtient alors, à l'étape référencée 707, un mot de passe devant correspondre au contenu à visualiser. Ceci peut être effectué, par exemple, en demandant, via son interface homme-machine, à l'utilisateur de fournir le mot de 15 passe qui lui a été préalablement communiqué (voir les étape référencées 616 et 620 sur la figure 6). Le contrôleur indique alors au noeud destinataire, à l'étape référencée 708, que la connexion est privée et qu'il doit mettre en oeuvre l'invention telle que décrite en relation avec la figure 5. Il envoie ensuite, lors d'une étape référencée 709, le mot de passe obtenu à l'étape référencée 707 au noeud destinataire, qui s'en servira pour 20 déterminer les paramètres Kx et Nc qu'il pourra fournir au terminal destinataire DTV 110 pour reconstruire la clé Kc et ainsi décrypter le contenu privé. Le contenu est donc ainsi correctement affiché par le téléviseur numérique DTV 110. Comme déjà précisé, le contrôleur peut être tout noeud du réseau 1000. Dans le cas où le contrôleur est confondu avec le noeud source ou le noeud destinataire, les 25 étapes d'envoi ou de transmission de données du contrôleur vers le noeud source ou le noeud destinataire réfèrent à des mécanismes internes d'échange d'informations qui ne nécessitent pas plus ample description, étant bien connus de l'homme du métier. Egalement, la présente invention peut être mise en oeuvre en utilisant tout protocole de protection de contenu possédant directement une phase d'échange de clé et 30 non de paramètres de clé. REVENDICATIONS 1. Procédé de transmission sécurisée d'un contenu privé entre un dispositif source (STB) et au moins un dispositif destination (DTV) à travers un noeud source (NAPO) auquel le dispositif source (STB) est connecté et au moins un noeud destination (NAP2) auquel ledit au moins dispositif destination (DTV) est connecté, lesdits dispositif source et noeud source utilisant un protocole de protection de contenu possédant une phase d'échange de paramètres de clé (Nc, Kx) et une phase de transmission de contenu crypté avec la clé associée aux paramètres de clé échangés, caractérisé en ce que le procédé comprend les étapes suivantes : -réception par le noeud source (NAPO) de paramètres (Kx, Nc) associés à une première clé pendant ladite phase d'échange de paramètres de clé entre le dispositif source et le noeud source (404); - réception par le noeud source (NAPO) du contenu crypté avec ladite première clé pendant ladite phase de transmission entre le dispositif source et le noeud source ; -transmission par le noeud source (NAPO) du contenu crypté au moins avec la première clé audit au moins un noeud destination (413); et association d'un mot de passe au contenu privé (407), permettant de conditionner l'accès par ledit au moins un noeud destination aux paramètres de clé associés à la première clé. 2. Procédé selon la revendication 1, caractérisé en ce que l'étape d'association d'un mot de passe au contenu privé est effectuée par un noeud contrôleur en charge d'établir une connexion entre le dispositif source et le dispositif destination pour la transmission du contenu privé, ladite étape d'association d'un mot de passe au contenu privé comprenant les étapes suivantes : - réception des paramètres (Kx, Nc) associés à la première clé et transmis par le noeud source (NAPO) ; - échange, à travers une interface utilisateur du noeud contrôleur, du mot de passe avec un utilisateur, le mot de passe étant défini par le noeud contrôleur ou l'utilisateur ; 2907287 34 - stockage du mot de passe dans une table d'association comprenant un identifiant dudit contenu, ledit mot de passe et les paramètres de clé associés à la première clé. 3. Procédé selon la revendication 2, caractérisé en ce que le mot de passe est défini 5 par le contrôleur et en ce que ledit mot de passe est obtenu en utilisant les paramètres de clé associés à la première clé. 4. Procédé selon la revendication 1, caractérisé en ce que l'étape d'association d'un mot de passe au contenu privé est effectuée par le noeud source (NAPO) et comprend les étapes suivantes : 10 - génération du mot de passe en utilisant les paramètres de clé associés à la première clé ; et fourniture du mot de passe à un utilisateur, à travers une interface utilisateur du noeud source (NAPO). 5. Procédé selon la revendication 1, caractérisé en ce que l'étape d'association d'un 15 mot de passe au contenu privé est effectuée par le noeud source (NAPO) et comprend les étapes suivantes : - génération du mot de passe en utilisant les paramètres de clé associés à la première clé ; et fourniture du mot de passe à un noeud contrôleur en charge d'établir une 20 connexion entre le dispositif source et le dispositif destination pour la transmission du contenu privé, et en ce que le procédé comprend en outre l'étape suivante, effectuée par le noeud contrôleur : - fourniture, à travers une interface utilisateur du noeud contrôleur, du mot de passe 25 à un utilisateur. 8. Procédé selon l'une des revendications 1 à 5, caractérisé en ce que ledit mot de passe est le résultat d'une fonction bijective appliquée aux paramètres de clé associés à la première clé. 9. Procédé selon la revendication 1, caractérisé en ce que l'étape d'association d'un mot de passe au contenu privé est effectuée par le noeud source (NAPO) et comprend les étapes suivantes : 2907287 génération du mot de passe en utilisant les paramètres de clé associés à la première clé ; - fourniture du mot de passe à un noeud contrôleur en charge d'établir une connexion entre le dispositif source et le dispositif destination pour la transmission du contenu privé, et en ce que le procédé comprend en outre les étapes suivantes, effectuées par le noeud contrôleur : - échange, à travers une interface utilisateur du noeud contrôleur, d'un second mot de passe avec un utilisateur, ledit second mot de passe étant défini par le noeud contrôleur ou l'utilisateur ; - stockage dudit second mot de passe dans une table d'association comprenant un identifiant dudit contenu, ledit mot de passe et ledit second mot de passe. 8. Procédé selon l'une des revendications 1 à 7, caractérisé en ce qu'il comprend en outre les étapes suivantes : 15 - cryptage avec une seconde clé, par le noeud source, du contenu crypté avec la première clé, afin d'obtenir un contenu doublement crypté ; - transmission par le noeud source de paramètres associés à la seconde clé, pendant une phase d'échange de paramètres de clé entre le noeud source et ledit au moins un noeud destination ; et 20 -transmission du contenu doublement crypté, pendant l'étape de transmission par le noeud source du contenu crypté au moins avec la première clé. 9. Procédé de réception sécurisée d'un contenu privé par au moins un dispositif destination (DTV) à travers au moins un noeud destination (NAP2) auquel ledit au moins dispositif destination (DTV) est connecté, lesdits dispositif destination et noeud 25 destination utilisant un protocole de protection de contenu possédant une phase d'échange de paramètres de clé (Nc, Kx) et une phase de transmission de contenu crypté avec la clé associée aux paramètres de clé échangés, caractérisé en ce que le procédé comprend les étapes suivantes : - réception par ledit au moins un noeud destination (NAP2) du contenu privé, 30 préalablement crypté avec une première clé et provenant d'un dispositif source 5 10 2907287 36 (STB, HI)D) à travers un noeud source (NAPO, NAP1) auquel ledit dispositif source est connecté (508); obtention d'un mot de passe associé au contenu privé (503); - détermination des paramètres de clé (Kx, Nc) associés à ladite première clé, par 5 l'utilisation du mot de passe obtenu dans l'étape d'obtention (504); transmission par ledit au moins un noeud destination (NAP2) desdits paramètres de clé au dispositif destination pendant ladite phase d'échange de paramètres de clé entre le noeud destination et le dispositif destination (505) ; et - transmission du contenu crypté avec la première clé reçu à l'étape de réception 10 au dispositif destination (510). 10. Procédé selon la revendication 9, caractérisé en ce que l'étape d'obtention d'un mot de passe et l'étape de détermination des paramètres de clé (Kx, Nc) associés à ladite première clé sont effectuées par ledit au moins un noeud destination (NAP2), et en ce que l'étape d'obtention d'un mot de passe est effectuée par la saisie dudit mot 15 de passe par un utilisateur, à travers une interface utilisateur dudit au moins un noeud destination (NAP2). 11. Procédé selon la revendication 9, caractérisé en ce que l'étape d'obtention d'un mot de passe et l'étape de détermination des paramètres de clé (Kx, Nc) associés à ladite première clé sont effectuées par un noeud contrôleur en charge d'établir une connexion 20 entre le dispositif source et le dispositif destination pour la réception du contenu privé, en ce que l'étape d'obtention d'un mot de passe est effectuée par la saisie dudit mot de passe par un utilisateur, à travers une interface utilisateur dudit noeud contrôleur, en ce que l'étape de détermination des paramètres de clé (Kx, Nc) est effectuée par la lecture, à partir clu mot de passe obtenu à l'étape d'obtention, d'une table d'association 25 comprenant un identifiant dudit contenu, ledit mot de passe et les paramètres de clé associés à la première clé, et en ce que le procédé comprend en outre une étape de transmission audit au moins un noeud destination (NAP2), par le noeud contrôleur, des paramètres (Kx, Nc) déterminés à l'étape de détermination. 30 12. Procédé selon la revendication 9, caractérisé en ce que l'étape d'obtention d'un mot de passe est effectuée par un noeud contrôleur en charge d'établir une connexion 2907287 37 entre le dispositif source et le dispositif destination pour la réception du contenu privé, ladite étape d'obtention d'un mot de passe étant effectuée par la saisie dudit mot de passe par un utilisateur, à travers une interface utilisateur dudit noeud contrôleur, en ce que le procédé comprend en outre une étape de transmission audit au moins un 5 noeud destination (NAP2), par le noeud contrôleur, du mot de passe obtenu à l'étape d'obtention, et en ce que l'étape de détermination des paramètres de clé (Kx, Nc) est effectuée par ledit au moins un noeud destination (NAP2) à partir du mot de passe transmis par le noeud contrôleur. 10 13. Procédé selon l'une des revendications 9 à 12, caractérisé en ce que le mot de passe obtenu à l'étape d'obtention est le résultat d'une fonction bijective appliquée aux paramètres de clé associés à la première clé et en ce que l'étape de détermination des paramètres de clé associés à la première clé est effectuée par application de la fonction inverse de la fonction bijective audit mot de passe. 15 14. Procédé selon la revendication 9, caractérisé en ce que l'étape d'obtention d'un mot de passe est effectuée par un noeud contrôleur en charge d'établir une connexion entre le dispositif source et le dispositif destination pour la réception du contenu privé, ladite étape d'obtention d'un mot de passe comprenant les étapes suivantes : - obtention d'un second mot de passe par la saisie dudit second mot de passe par 20 un utilisateur, à travers une interface utilisateur dudit noeud contrôleur ; - détermination dudit mot de passe par la lecture, à partir dudit second mot de passe, d'une table d'association comprenant un identifiant dudit contenu, ledit mot de passe et ledit second mot de passe ; en ce que le procédé comprend en outre une étape de transmission audit au moins un 25 noeud destination (NAP2), par le noeud contrôleur, du mot de passe obtenu à l'étape de détermination dudit mot de passe, et en ce que l'étape de détermination des paramètres de clé (Kx, Nc) est effectuée par ledit au moins un noeud destination (NAP2) à partir du mot de passe transmis par le noeud contrôleur. 2907287 38 15. Procédé selon l'une des revendications 9 à 14, caractérisé en ce que le contenu reçu par le noeud destination est doublement crypté avec la première clé et une seconde clé et en ce que le procédé comprend en outre les étapes suivantes : - une étape d'authentification et d'échange de paramètres de clé associés à la 5 seconde clé entre le noeud source et le noeud destination ; et - décryptage, avec la seconde clé, du contenu doublement crypté, afin d'obtenir le contenu crypté uniquement avec la première clé. 16. Produit programme d'ordinateur téléchargeable depuis un réseau de communication e:t/ou enregistré sur un support lisible par ordinateur et/ou exécutable par 10 un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution des étapes du procédé de transmission sécurisée selon au moins une des revendications 1 à 8 et/ou du procédé de réception sécurisée selon au moins une des revendications 9 à 15, lorsque ledit programme est exécuté sur un ordinateur. 17. Moyen de stockage, éventuellement totalement ou partiellement amovible, lisible 15 par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé de transmission sécurisée selon au moins une des revendications 1 à 8 et/ou le procédé de réception sécurisée selon au moins une des revendications 9 à 15. 18. Noeud source (NAPO) pouvant participer à la transmission sécurisée d'un 20 contenu privé entre un dispositif source (STB) et au moins un dispositif destination (DTV) à travers ledit noeud source (NAPO) auquel le dispositif source (STB) est connecté et au moins un noeud destination (NAP2) auquel ledit au moins dispositif destination (DTV) est connecté, lesdits dispositif source et noeud source utilisant un protocole de protection de contenu possédant une phase d'échange de paramètres de clé 25 (Nc, Kx) et une phase de transmission de contenu crypté avec la clé associée aux paramètres de clé échangés, caractérisé en ce que le noeud source comprend : - des moyens de réception de paramètres (Kx, Nc) associés à une première clé pendant ladite phase d'échange de paramètres de clé entre le dispositif source et le noeud source ; 30 - des moyens de réception du contenu crypté avec ladite première clé pendant ladite phase de transmission entre le dispositif source et le noeud source ; 2907287 39 - des moyens de transmission du contenu crypté au moins avec la première clé audit au rnoins un noeud destination, un mot de passe étant associé au contenu privé, permettant de conditionner l'accès par ledit au moins un noeud destination aux paramètres de clé associés à la première clé. 5 19. Noeud source (NAPO) selon la revendication 18, caractérisé en ce qu'il comprend des moyens de transmission des paramètres (Kx, Nc) associés à la première clé à un noeud contrôleur en charge d'établir une connexion entre le dispositif source et le dispositif destination pour la transmission du contenu privé, afin que ledit noeud contrôleur effectue l'association d'un mot de passe au contenu privé. 10 20. Noeud source (NAPO) selon la revendication 18, caractérisé en ce que, pour effectuer l'association d'un mot de passe au contenu privé, il comprend : - des moyens de génération du mot de passe en utilisant les paramètres de clé associés à la première clé ; et - des moyens de fourniture du mot de passe à un utilisateur, à travers une interface 15 utilisateur du noeud source (NAPO). 21. Noeud source (NAPO) selon la revendication 18, caractérisé en ce que, pour effectuer l'association d'un mot de passe au contenu privé, il comprend : - des moyens de génération du mot de passe en utilisant les paramètres de clé associés à la première clé ; et 20 - des moyens de fourniture du mot de passe à un noeud contrôleur en charge d'établir une connexion entre le dispositif source et le dispositif destination pour la transmission du contenu privé, afin que le noeud contrôleur fournisse, à travers une interface utilisateur du noeud contrôleur, le mot de passe à un utilisateur. 22. Noeud source (NAPO) selon l'une des revendications 18 à 21, caractérisé en ce 25 que ledit mot de passe est le résultat d'une fonction bijective appliquée aux paramètres de clé associés à la première clé. 23. Noeud source (NAPO) selon la revendication 18, caractérisé en ce que, pour effectuer l'association d'un mot de passe au contenu privé, il comprend : - des moyens de génération du mot de passe en utilisant les paramètres de clé 30 associés à la première clé ; 2907287 - des moyens de fourniture du mot de passe à un noeud contrôleur en charge d'établir une connexion entre le dispositif source et le dispositif destination pour la transmission du contenu privé, afin que le noeud contrôleur : * échange, à travers une interface utilisateur du noeud contrôleur, un second 5 mot de passe avec un utilisateur, ledit second mot de passe étant défini par le noeud contrôleur ou l'utilisateur ; * stocke ledit second mot de passe dans une table d'association comprenant un identifiant dudit contenu, ledit mot de passe et ledit second mot de passe. 10 24. Noeud source (NAPO) selon l'une des revendications 18 à 23, caractérisé en ce qu'il comprend : - des moyens de cryptage avec une seconde clé du contenu crypté avec la première clé, afin d'obtenir un contenu doublement crypté ; - des moyens de transmission de paramètres associés à la seconde clé, pendant une 15 phase d'échange de paramètres de clé entre le noeud source et ledit au moins un noeud destination ; et en ce que lesdits moyens de transmission du contenu crypté au moins avec la première clé transmettent ledit contenu doublement crypté. 25. Noeud destination (NAP2) pouvant participer à la réception sécurisée d'un 20 contenu privé par au moins un dispositif destination (DTV) à travers au moins ledit noeud destination (NAP2) auquel ledit au moins dispositif destination (DTV) est connecté, lesdits dispositif destination et noeud destination utilisant un protocole de protection de contenu possédant une phase d'échange de paramètres de clé (Nc, Kx) et une phase de transmission de contenu crypté avec la clé associée aux paramètres de clé 25 échangés, caractérisé en ce qu'il comprend : - des moyens de réception du contenu privé, préalablement crypté avec une première clé et provenant d'un dispositif source (STB, HDD) à travers un noeud source (NAPO, NAP1) auquel ledit dispositif source est connecté ; -des moyens de réception ou détermination des paramètres de clé (Kx, Nc) 30 associés à ladite première clé, lesdits paramètres de clé étant déterminés par l'utilisation d'un mot de passe associé au contenu privé et préalablement obtenu; 2907287 41 - des moyens de transmission desdits paramètres de clé au dispositif destination pendant ladite phase d'échange de paramètres de clé entre le noeud destination et le dispositif destination ; et - des moyens de transmission au dispositif destination du contenu crypté avec la première clé reçu par les moyens de réception. 26. Noeud destination (NAP2) selon la revendication 25, caractérisé en ce qu'il comprend : - des moyens d'obtention dudit mot de passe, par la saisie dudit mot de passe par un utilisateur, à travers une interface utilisateur dudit au moins un noeud destination (NAP2) ; et - des moyens de détermination des paramètres de clé (Kx, Nc) associés à ladite première clé, à partir du mot de passe obtenu. 27. Noeud destination (NAP2) selon la revendication 25, caractérisé en ce qu'il comprend des moyens de réception des paramètres de clé (Kx, Nc) associés à ladite 15 première clé, lesdits paramètres de clé étant déterminés et transmis par un noeud contrôleur en charge d'établir une connexion entre le dispositif source et le dispositif destination pour la réception du contenu privé. 28. Noeud destination (NAP2) selon la revendication 25, caractérisé en ce qu'il comprend : 20 - des moyens de réception dudit mot de passe obtenu par un noeud contrôleur en charge d'établir une connexion entre le dispositif source et le dispositif destination pour la réception du contenu privé ; et - des moyens de détermination des paramètres de clé (Kx, Nc) associés à ladite première clé, à partir du mot de passe reçu. 25 29. Noeud destination (NAP2) selon l'une des revendications 25 à 28, caractérisé en ce que le mot de passe obtenu est le résultat d'une fonction bijective appliquée aux paramètres de clé associés à la première clé, et en ce que les moyens de détermination des paramètres de clé associés à la première clé appliquent la fonction inverse de la fonction bijective audit mot de passe. 5 10 5 2907287 42 30. Noeud destination (NAP2) selon l'une des revendications 25 à 29, caractérisé en ce que le contenu reçu par le noeud destination est doublement crypté avec la première clé et une seconde clé et en ce que le noeud destination comprend : - des moyens d'authentification et d'échange de paramètres de clé associés à la seconde clé, entre le noeud source et le noeud destination ; et - des moyens de décryptage, avec la seconde clé, du contenu doublement crypté, afin d'obtenir le contenu crypté uniquement avec la première clé.