FR2906097A1

FR2906097A1 - Procedes d'echange de donnees securises, produit programme d'ordinateur, moyen de stockage et dispositifs correspondants.

Info

Publication number: FR2906097A1
Application number: FR0608103A
Authority: FR
Inventors: Pascal Lagrange
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2006-09-15
Filing date: 2006-09-15
Publication date: 2008-03-21
Anticipated expiration: 2026-09-15
Also published as: FR2906097B1

Abstract

L'invention concerne un procédé d'échange de données sécurisé entre un premier dispositif et un second dispositif dans un réseau de communication comprenant une pluralité de dispositifs, lesdits premier et second dispositifs utilisant un protocole de protection de contenu comprenant une première authentification dans le cadre de l'initialisation d'une première connexion entre au moins les premier et second dispositifs.Selon l'invention, un tel procédé comprend les étapes suivantes :- détection d'un événement pour échanger au moins une information complémentaire ;- seconde authentification (308 ; 510) avec le second dispositif dans le cadre de l'initialisation d'une seconde connexion pour échanger ladite information complémentaire, la première connexion étant active, ladite seconde authentification étant mise en oeuvre après la détection dudit événement.

Description

1 Procédés d'échange de données sécurisés, 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 contre la copie de données transmises entre plusieurs dispositifs terminaux dans un tel réseau. L'invention s'applique notamment, mais non exclusivement, dans le cas d'un réseau multimédia, où le flux de données transporte des données de type audio-vidéo (AV). 2. Solutions de l'art antérieur Les équipements modernes dont une famille peut s'équiper ont souvent pour tâche de transmettre des données de nature différente comme de la vidéo, du son, des photos, des fichiers de texte et autres. La transmission de ces données est soumise à des exigences variables selon le type de données considéré. Ces données doivent notamment être véhiculées au moyen de câbles ou de liens adaptés. Ainsi, à chaque format de données, correspond un moyen de transport adapté et un type de connecteur permettant de relier des équipements entre eux. Par exemple, les équipements traitant des données numériques peuvent fonctionner selon la norme IEEE-1394.

L'invention s'applique notamment, mais non exclusivement, dans le cas d'un réseau audio-vidéo, par exemple un réseau domestique, comprenant un réseau fédérateur comprenant lui-même des noeuds interconnectés entre eux par des liens numériques. Aux noeuds sont reliés des équipements à travers des liens qui peuvent être analogiques ou numériques. 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 High Performance 2906097 2 Serial Bus Bridges , au standard Ethernet, ou au standard de communication radio IEEE 802.11. La figure 1 illustre un exemple d'un tel réseau audio-vidéo domestique 1000. Ce réseau domestique 1000 est par exemple un réseau LAN et comprend un 5 réseau fédérateur 1001 comprenant lui-même des noeuds 000, 001, 002, 003 interconnectés via des liens numériques 016 à 020 de type câbles Ethernet que l'on pourra également désigner par liens IP. Les noeuds 000 à 003 peuvent être également appelés point d'accès au réseau (ou Network Access Point désigné dans la suite par NAP). 10 Le noeud 000 est connecté au noeud 001 via le lien Ethernet 017, au noeud 002 via le lien Ethernet 016 et au noeud 003 via le lien Ethernet 019. Le noeud 002 est connecté au noeud 001 via le lien Ethernet 018 et au noeud 003 via le lien Ethernet 020. Dans une variante, les noeuds 000 à 003 sont également interconnectés via 15 une unité centrale de commutation comprenant plusieurs équipements de commutation qui sont insérés dans les cloisons d'une habitation ou sont indépendants des cloisons et être ainsi déplaçables. Le noeud 000 est également connecté à un terminal 010 de type serveur (qui est par exemple un boîtier décodeur ou set-top-box en anglais) via un lien 004 20 numérique, que l'on pourra également désigner par lien audio-vidéo. Le noeud 001 est également connecté à un terminal 011 de type client (qui est ici par exemple un premier disque dur audio-vidéo qui constitue une première unité de stockage) via un lien 005 numérique et à un terminal 0012 de type serveur (qui est ici par exemple un magnétoscope numérique) via un lien 25 006 numérique. Le noeud 002 est également connecté à un terminal 013 de type client/serveur (qui est par exemple un lecteur/enregistreur DVD) via un lien 007 numérique. Le noeud 003 est également connecté à un terminal 014 de type serveur (qui est ici par exemple un second disque dur audio-vidéo qui constitue une 2906097 3 seconde unité de stockage) via un lien 008 numérique et à un terminal 0015 de type client (qui est ici par exemple une télévision numérique) via un lien 009 numérique. Les liens 004 à 009 sont, par exemple, conformes au protocole Ethernet. 5 Ainsi le réseau 1000 comprend deux types de dispositifs ou équipements que sont les terminaux et les noeuds. On entend par : - dispositif de type client, un dispositif qui est capable de recevoir des contenus de données ; 10 -dispositif de type serveur, un dispositif qui est capable d'émettre des contenus de données ; - dispositif de type client/serveur, un dispositif qui est à la fois capable de recevoir et d'émettre des contenus de données. Au sens du document de référence : Digital Transmission Content 15 Protection Specification, Volume 1 et 2, Draft 1.29 : un dispositif client peut être vu comme un dispositif récepteur ; un dispositif serveur peut être vu comme un dispositif source ; un dispositif client/serveur peut être vu à la fois comme un dispositif récepteur et un dispositif source. 20 Une technique connue afin de garantir la protection contre la copie de flux isochrones tels que des contenus audio-vidéo dans un réseau de communication de données est la mise en oeuvre du protocole DTCP (pour Digital Transfer Content Protection en anglais et protection de contenus en transmission numérique en français) en cascade. Les caractéristiques et recommandations de 25 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 . La figure 2 illustre la mise en oeuvre du protocole DTCP lors de la transmission d'un contenu entre un dispositif source, référencé A, et un dispositif récepteur, référencé B. 2906097 4 Le protocole DTCP classique comprend une phase d'authentification mutuelle et d'échange de clés 200 entre le dispositif récepteur B et le dispositif source A, suivi d'une phase de cryptage/décryptage 220 mise en oeuvre entre ces deux dispositifs A et B. 5 La phase d'authentification et d'échange de clés 200 comprend les étapes suivantes : - dans une é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 ; 10 - dans une étape 202, le dispositif source A vérifie les informations d'authentification du dispositif récepteur B, puis identifie le numéro de version de la liste de révocation SRM (pour System Renewability Message ) du dispositif récepteur et calcul une première valeur de phase EC-DH ; 15 - dans une é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 étape 204, le dispositif récepteur B vérifie les informations d'authentification du dispositif source A, puis identifie le numéro de 20 version de la liste de révocation SRM du dispositif source et calcul une première valeur de phase EC-DIl ; - dans une étape 205, le dispositif source A envoie au dispositif récepteur B un premier message signé comprenant des informations spécifiques au protocole DTCP ; 25 dans une é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 ; - dans une é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 ; 2906097 5 -dans une étape 208, le dispositif source A contrôle le second message signé du dispositif récepteur B et calcule une seconde clé d'authentification ; - dans une étape 217, le dispositif source A génère une clé d'échange Kx ; 5 - dans une étape 218, la clé d'échange Kx est cryptée au moyen de la seconde clé d'authentification puis est envoyée par le dispositif source A au dispositif récepteur B ; - dans une étape 219, le dispositif récepteur B calcul la clé d'échange Kx ; - puis, le dispositif source A génère une information aléatoire, par exemple 10 un nombre aléatoire Nc, et calcule une clé de cryptage Kc qui est une fonction notamment de ce nombre aléatoire Nc et qui vérifie Kc =J[Kx, EMI, Nc], où J est une fonction déterminée, EMI et Kx des paramètres classiques du protocole DTCP ; - ensuite, le nombre aléatoire Nc est envoyé par le dispositif source A au 15 dispositif récepteur B ; - ensuite, le dispositif récepteur B calcule la clé de cryptage Kc au moyen du nombre aléatoire Nc ; - lors d'une étape 212 d'échange de liste de révocation SRM entre les dispositifs source A et récepteur B, le dispositif source A met à jour (si sa 20 liste est postérieure à celle de B) la liste SRM du dispositif récepteur (étape 211) ou le dispositif récepteur B met à jour (si sa liste est postérieure à celle de A) la liste SRM du dispositif source A (étape 213). La phase de cryptage/décryptage 220 comprend les étapes suivantes : - dans une étape 214, le dispositif source A crypte, en appliquant une 25 fonction fKc déterminée, le contenu au moyen de la clé de cryptage Kc de manière à obtenir un contenu crypté ; - dans une étape 215, le dispositif source A envoie le contenu crypté au dispositif récepteur B ; 2906097 6 dans une étape 216, le dispositif récepteur B décrypte le contenu crypté au moyen de la clé de cryptage Kc, en appliquant une fonction f-'Kc (qui est la fonction réciproque de la fonction fKc). Ainsi, le protocole DTCP, visant à protéger des contenus transmis via des 5 bus numériques, comprend un mécanisme de communication (étape 204) et de mise à jour (étape 212) de listes de révocation SRM (comprenant une liste des dispositifs révoqués et étant caractérisée par un numéro de version) lors de la phase d'authentification 200 (et uniquement lors de cette phase). On se place, par exemple dans le cas où le noeud 000 dispose d'une liste de 10 révocation SRM dont la version n'est pas à jour et le noeud 001 dispose d'une liste SRM dont la version est à jour. Du fait des spécificités du protocole DTCP, ce mécanisme de communication de liste de révocation SRM est prévu pour des connexions point à point et n'est donc pas bien adapté à une utilisation en réseau. 15 En effet, tant que le noeud 000 n'a pas établi une connexion avec le noeud 001, il conserve, dans toutes ses connexions avec d'autres dispositifs disposant de listes SRM non à jour, sa liste SRM non à jour et risque donc d'autoriser, à tort, un dispositif révoqué postérieurement à la date d'établissement de sa liste SRM à avoir accès à un contenu ou à établir une connexion. 20 Par ailleurs, si le noeud 001 vient de mettre à jour sa liste de révocation (au moyen par exemple d'une authentification avec le noeud 002) alors qu'il s'est déjà authentifié avec le noeud 000 (lors de l'échange d'un contenu par exemple), alors il n'est plus possible (conformément au protocole DTCP) au noeud 000 d'avoir accès à la liste de révocation à jour du noeud 001. 25 En effet, une des spécificités du protocole DTCP est que, lorsqu'une authentification a été établie et est toujours valable, il n'est pas possible de mettre en oeuvre une autre phase d'authentification. On se place maintenant dans le cadre d'un réseau de communication dont le schéma est présenté en figure 3. 2906097 7 On suppose que le réseau met en oeuvre un protocole de protection de contenu qui est le protocole DTCP. Dans ce réseau, des noeuds clients 401, 402 et 403 sont connectés à un noeud adaptateur 400 grâce à des liens numériques 404, 405 et 406. Un noeud 5 serveur 407 est connecté au noeud adaptateur 400 grâce à un lien numérique 408. Par exemple, les liens numériques 404, 405, 406 et 408 sont des liens Ethernet ou des liens IEEE-1394 (bien entendu, ils peuvent être conformes à tout autre protocole de communication numérique). Lorsqu'ils souhaitent accéder à un contenu numérique préalablement 10 stocké sur le noeud serveur 407, les noeuds clients 401, 402 et 403 doivent mettre en oeuvre une phase d'authentification et d'échange de clé conforme au protocole DTCP avec le noeud adaptateur 400. Cette phase conduit au partage entre les noeuds clients 401, 402 et 403 d'une même clé de cryptage noté KcO. Ceci permet au noeud adaptateur 400 de transmettre le contenu crypté au moyen de la clé Kc0 à 15 chacun des noeuds clients 401, 402 et 403. Cependant, le protocole DTCP mis en oeuvre dans le réseau de communication de la figure 3 ne permet pas, à lui seul, de faire en sorte qu'un noeud client donné du réseau mettant en oeuvre le protocole DTCP, par exemple le noeud client 403, puisse accéder à un contenu c, via le noeud adaptateur 400, sur le 20 noeud serveur 407 de manière privée ; c'est-à-dire en interdisant aux autres noeuds clients 401 et 402 d'accéder au même contenu c de manière claire. 3. Objectifs de l'invention L'invention a pour objectif de pallier ces inconvénients de l'art antérieur. Plus précisément, un objectif de l'invention, dans au moins un de ses 25 modes de réalisation, est de fournir une technique permettant une mise à jour efficace des listes de révocation SRM des noeuds et terminaux d'un réseau de communication mettant en oeuvre un protocole de protection de contenus de type point à point comprenant une phase d'authentification et d'échange de clés. Un autre objectif de l'invention, dans au moins un de ses modes de 30 réalisation, est de mettre en oeuvre une telle technique qui permette, dans un 2906097 8 réseau de communication mettant en oeuvre un protocole de protection de contenus de type point à point, de restreindre, à un premier dispositif parmi plusieurs dispositifs connectés à un second dispositif, l'accès à un contenu disponible sur un troisième dispositif connecté au second dispositif. 5 Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de mettre en oeuvre une telle technique qui soit transparente pour les terminaux, et ceci en limitant la charge du réseau. L'invention a encore pour objectif, dans au moins un de ses modes de réalisation, de fournir une telle technique qui soit sûre, simple à mettre en oeuvre 10 et peu coûteuse. 4. Caractéristiques essentielles de l'invention Ces objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints à l'aide d'un procédé d'échange de données sécurisé entre un premier dispositif et un second dispositif dans un réseau de communication comprenant une pluralité 15 de dispositifs, lesdits premier et second dispositifs utilisant un protocole de protection de contenu comprenant une première authentification dans le cadre de l'initialisation d'une première connexion entre au moins les premier et second dispositifs. Selon l'invention, un tel procédé comprend en outre les étapes suivantes 20 mises en oeuvre par le premier dispositif : - détection d'un événement pour échanger au moins une information complémentaire ; seconde authentification avec le second dispositif dans le cadre de l'initialisation d'une seconde connexion pour échanger ladite information 25 complémentaire, la première connexion étant active, ladite seconde authentification étant mise en oeuvre après la détection dudit événement. Le principe général de l'invention repose sur l'adaptation d'un protocole de protection de contenu de type point à point de sorte qu'il mettent en oeuvre au moins une seconde authentification dans le cadre de l'initialisation d'une seconde 30 connexion alors qu'une première connexion initiée par une première 2906097 9 authentification est pendante afin, par exemple, de permettre la mise à jour efficace des listes de révocation des noeuds et terminaux du réseau de communication. Par exemple un événement est la mise en oeuvre d'un procédé de mise à 5 jour de liste de révocation tel que ci-après décrit. Avantageusement, les première et seconde connexions sont respectivement associées à des première et seconde adresses du premier dispositif, ladite première adresse étant distincte de ladite seconde adresse. Selon une première caractéristique avantageuse de l'invention, les 10 première et seconde adresses sont associées à des premier et second ports de sortie du premier dispositif. Selon une seconde caractéristique avantageuse de l'invention, les première et seconde adresses sont obtenues auprès d'un serveur d'adresses compris dans le réseau de communication. 15 Avantageusement, le protocole de protection de contenu est le protocole DTCP-IP. Selon un premier mode de mise en oeuvre de l'invention, lesdits premier et second dispositifs comprenant une liste de révocation associée au protocole de protection de contenu, l'événement détecté étant une différence entre les listes de 20 révocation desdits premier et second dispositifs et l'information complémentaire étant la liste de révocation la plus récente. Avantageusement, le procédé d'échange sécurisé comprend les étapes suivantes mises en oeuvre par le premier dispositif pour au moins le second dispositif : 25 - détermination si la liste de révocation du second dispositif est antérieure à la liste de révocation du premier dispositif ; si la liste de révocation du second dispositif est antérieure à la liste de révocation du premier dispositif, mise à jour de la liste de révocation du second dispositif au moyen de la liste de révocation du premier dispositif. 2906097 10 Ainsi, selon un premier mode de réalisation, la mise à jour des dispositifs du réseau est effectuée de proche en proche et peut donc être réalisée rapidement. Cependant, chacun des dispositifs qui met à jour au moins un autre dispositif doit comprendre des moyens de mise à jour de liste(s) de révocation, dont notamment 5 deux adresses. Selon un second mode de réalisation, la mise à jour des dispositifs du réseau est effectuée par le dispositif gestionnaire uniquement. Ainsi, seul le dispositif gestionnaire doit comprendre des moyens de mise à jour de liste(s) de révocation (dont notamment deux adresses) ce qui permet de rendre le réseau plus 10 simple à mettre en oeuvre et de manière peu coûteuse. Avantageusement, le procédé d'échange sécurisé comprend au préalable les étapes suivantes : réception d'une liste de révocation d'un troisième dispositif du réseau de communication ; 15 - mise à jour de la liste de révocation du premier dispositif avec la liste de révocation reçue. Bien entendu, toute autre technique de mise à jour de la liste de révocation du dispositif gestionnaire peut être envisagée, dont notamment une mise à jour par fourniture, par un utilisateur du réseau, au dispositif gestionnaire, d'une nouvelle 20 liste de révocation. Selon un second mode de mise en oeuvre, l'événement détecté est une requête d'échange d'un contenu privé entre les premier et second dispositifs et en ce que l'information complémentaire comprend des paramètres de clé de cryptage correspondants à la seconde connexion. 25 Ainsi, le procédé de transmission selon l'invention permet, dans le réseau de communication mettant en oeuvre un protocole de protection de contenus de type point à point, de restreindre, à un dispositif, l'accès à un contenu disponible sur un autre dispositif. 2906097 11 Par exemple, afin d'empêcher qu'un premier dispositif n'accède à un contenu stocké sur un second dispositif et destiné à un troisième dispositif, on peut : interdire au premier dispositif la participation à une première 5 authentification permettant d'établir une première connexion entre les second et troisième dispositifs permettant de transmettre ce contenu, afin que le premier dispositif puisse quand même communiquer avec le second dispositif, donner, au premier noeud, la possibilité de réaliser une seconde connexion avec le premier dispositif au moyen d'une seconde 10 authentification. L'invention concerne également un procédé d'échange de données sécurisé entre un premier dispositif et un second dispositif dans un réseau de communication comprenant une pluralité de dispositifs, lesdits premier et second dispositifs utilisant un protocole de protection de contenu comprenant une 15 première authentification dans le cadre de l'initialisation d'une première connexion entre au moins les premier et second dispositifs. Selon l'invention, le procédé comprend les étapes suivantes mises en oeuvre par le premier dispositif : seconde authentification avec le second dispositif dans le cadre de 20 l'initialisation d'une seconde connexion pour transmettre au moins une information complémentaire, la première connexion étant active, ladite seconde authentification étant mise en oeuvre après la détection dudit événement. Avantageusement, le protocole de protection de contenu est le protocole 25 DTCP-IP. L'invention concerne également un produit programme d'ordinateur, comprenant des instructions de code de programme pour l'exécution des étapes des procédés d'échange tels que décrits précédemment. L'invention concerne également un moyen de stockage lisible par un 30 ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour 2906097 12 mettre en oeuvre les procédés d'échange tels que décrits précédemment. L'invention concerne également un premier dispositif comprenant des moyens d'échange de données sécurisé avec un second dispositif, lesdits premier et second dispositifs appartenant à un réseau de communication comprenant une 5 pluralité de dispositifs, lesdits moyens d'échange comprenant des premiers moyens d'initialisation, permettant d'initialiser une première connexion entre le premier dispositif et au moins le second dispositif conformément à un protocole de protection de contenu, lesdits premiers moyens d'initialisation comprenant des premiers moyens d'authentification du premier dispositif avec le second dispositif 10 conformément au protocole de protection de contenu. Selon l'invention, les moyens de transmission comprennent : des moyens de détection d'un événement pour échanger au moins une information complémentaire ; des seconds moyens d'initialisation, permettant d'initialiser une seconde 15 connexion entre le premier dispositif et le second dispositif conformément au protocole de protection de contenu pour échanger ladite information complémentaire, lesdits seconds moyens d'initialisation comprenant des seconds moyens d'authentification du premier dispositif avec le second dispositif conformément au protocole de protection de contenu ; 20 - des moyens d'activation des seconds moyens d'initialisation qui active les seconds moyens d'initialisation si la première connexion est active et si l'événement est détectée. Les avantages du premier dispositif sont sensiblement les mêmes que ceux des procédés d'échange sécurisé, ils ne sont pas détaillés plus amplement. 25 Avantageusement, les première et seconde connexions sont respectivement associées à des première et seconde adresses du premier dispositif, ladite première adresse étant distincte de ladite seconde adresse. Préférentiellement, les première et seconde adresses sont associées à des premier et second ports de sortie du premier dispositif. 30 Avantageusement, le premier dispositif comprend des moyens d'obtention 2906097 13 des première et seconde adresses auprès d'un serveur d'adresses compris dans le réseau de communication. Préférentiellement, le protocole de protection de contenu est le protocole DTCP-IP. 5 Avantageusement, les premier et second dispositifs comprennent une liste de révocation associée au protocole de protection de contenu, l'événement détecté est une différence entre les listes de révocation desdits premier et second dispositifs et l'information complémentaire est la liste de révocation la plus récente. 10 Avantageusement, le premier dispositif comprend : des moyens de détermination si la liste de révocation du second dispositif est antérieure à la liste de révocation du premier dispositif ; des moyens de mise à jour de la liste de révocation du second dispositif au moyen de la liste de révocation du premier dispositif, lesdits moyens de 15 mise à jour étant activés si la liste de révocation du second dispositif est antérieure à la liste de révocation du premier dispositif. Avantageusement, le premier dispositif comprend : des moyens de réception d'une liste de révocation d'un troisième dispositif du réseau de communication 20 - des moyens de mise à jour de la liste de révocation du premier dispositif avec la liste de révocation reçue. Selon une caractéristique avantageuse de l'invention, l'événement détecté est une requête d'échange d'un contenu privé entre les premier et second dispositifs et l'information complémentaire comprend des paramètres de clé de 25 cryptage correspondants à la seconde connexion. L'invention concerne également un premier dispositif comprenant des moyens d'échange de données sécurisé avec un second dispositif, lesdits premier et second dispositifs appartenant à un réseau de communication comprenant une pluralité de dispositifs, lesdits moyens de réception comprenant des premiers 30 moyens d'initialisation permettant d'initialiser une première connexion entre le 2906097 14 premier dispositif et au moins le second dispositif conformément à un protocole de protection de contenu, lesdits premiers moyens d'initialisation comprenant des premiers moyens d'authentification du premier dispositif avec le second dispositif conformément au protocole de protection de contenu. 5 Selon l'invention, les moyens d'échange comprennent : des seconds moyens d'initialisation permettant d'initialiser une seconde connexion entre le premier dispositif et le second dispositif conformément au protocole de protection de contenu pour échanger au moins une information complémentaire, lesdits seconds moyens d'initialisation 10 comprenant des seconds moyens d'authentification du premier dispositif avec le second dispositif conformément au protocole de protection de contenu ; des moyens d'activation des seconds moyens d'initialisation qui active les seconds moyens d'initialisation si la première connexion est active. 15 Avantageusement, le protocole de protection de contenu est le protocole DTCP-IP. 5. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante de plusieurs modes de réalisation 20 préférentiels, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels : la figure 1 présente le schéma d'un réseau audio-vidéo domestique hétérogène dans lequel peut être mis en oeuvre le procédé de l'invention ; 25 - la figure 2 illustre la mise en oeuvre du protocole DTCP classique lors de la transmission d'un contenu cO entre un dispositif source et un dispositif récepteur; la figure 3 présente un schéma d'un réseau de communication ; la figure 4 présente le schéma d'une implémentation d'un noeud du réseau 30 domestique hétérogène de la figure 1 selon un mode de mise en oeuvre 2906097 15 particulier de l'invention ; la figure 5 illustre les étapes principales de procédés de mise à jour des listes de révocation SRM des dispositifs du réseau domestique de la figure 1, selon des premier et second modes de réalisation préférentiels de 5 l'invention ; la figure 6 présente les étapes d'un algorithme d'établissement d'une connexion HTTP, conforme au procédé d'échange sécurisé selon l'invention, entre le noeud gestionnaire SRM (se comportant comme un client HTTP) et un dispositif serveur http ; 10 - la figure 7 présente les étapes d'un algorithme d'établissement d'une connexion HTTP, conforme au procédé d'échange sécurisé selon l'invention, entre le noeud gestionnaire SRM (se comportant comme un serveur HTTP) et un dispositif client http ; la figure 8 les étapes principales du procédé d'échange sécurisé du contenu 15 c à accès restreint du noeud serveur 407 au noeud client 403 dans le réseau de la figure 3 selon un troisième modede réalisation de l'invention. 6. Description de plusieurs modes de réalisation de l'invention On se place, dans la suite, dans le cadre du réseau domestique hétérogène 1000 de la figure 1 (qui est par exemple un réseau LAN) mettant en oeuvre le 20 protocole de communication Ethernet. Ainsi, les liens numériques 004 à 009 et 016 à 020 sont des liens Ethernet. Bien entendu, le réseau 1000 pourrait également mettre en oeuvre le protocole de communication IEEE-1394, le protocole USB, le protocole MOST ou même tout autre protocole de communication compatible avec un procédé de 25 protection de contenu. D'autre part, le réseau 1000 pourrait mettre en oeuvre plusieurs protocoles de communication différents simultanément. Il est clair, par ailleurs, que l'invention peut être mise en oeuvre dans tout réseau de communication comprenant au moins un dispositif source connecté à au 30 moins un dispositif récepteur. 2906097 16 Ensuite, l'invention s'applique également dans le cas d'un réseau avec un nombre quelconque de dispositifs sources et de dispositifs récepteurs (les dispositifs pouvant être des noeuds ou des terminaux). Par ailleurs, on considère dans la suite qu'un procédé d'échange de 5 données sécurisé selon un mode de mise en oeuvre préférentiel de l'invention est mis en oeuvre dans le réseau domestique 1000. Tel qu'illustré ci-après, en relation avec la figure 5, le procédé d'échange de données sécurisé de l'invention est basé sur le protocole DTCP précité. Cependant, il est évident que ces procédés selon l'invention pourrait 10 également être basé sur tout protocole de protection de contenus comprenant une phase préalable d'authentification (et pas seulement le protocole DTCP). Le procédé d'échange de données sécurisé selon l'invention est mis en oeuvre sous la forme d'un logiciel et/ou d'une pluralité de sous logiciels (comprenant une pluralité d'algorithmes décrits ci-après) qui est (sont) exécuté(s) 15 dans une ou plusieurs machines du réseau 1000. Un procédé de mise à jour de liste de révocation selon l'invention (ci-après décrit en relation avec la figure 5) est mis en oeuvre sous la forme de logiciels et/ou de pluralités de sous logiciels (comprenant une pluralité d'algorithmes décrits ci-après) qui est (sont) exécuté(s) dans une ou plusieurs machines du 20 réseau 1000, par exemple dans le noeud 002 (les noeuds 000, 001 et 003 étant identique au noeud 003) décrit ci-après en relation avec la figure 4. On présente, en relation avec la figure 4, le schéma d'une implémentation du noeud 002 compatible avec le procédé d'échange de données sécurisé de l'invention, du réseau domestique 1000 selon un mode de réalisation particulier de 25 l'invention. On ne décrit, par soucis de simplicité, que ce noeud de générique 002 qui comprend des moyens de cryptage/décryptage ainsi que des moyens d'authentification. On comprend qu'il peut représenter par exemple l'un des noeuds 000, 001 ou 003 du réseau domestique 1000 de la figure 1. Le noeud 002 est connecté à la fois au réseau fédérateur 1001 via les liens 30 Ethernet 016, 018 et 020 et au dispositif terminal 013 (par exemple un boîtier 2906097 17 décodeur STB, un téléviseur numérique DTV ou un lecteur de disque dur numérique HDD) de type client/serveur via le lien numérique 007 (lien IEEE 1394). Le noeud 002 comprend un premier module d'interface 101 avec le bus 5 numérique du lien IEEE 1394 007 le reliant avec le dispositif terminal 013 et un second module d'interface numérique 113 avec, par exemple, le lien Ethernet 016 le reliant au noeud 000 du réseau fédérateur 1001. Il comprend également un module FIFO ( First in First out en anglais ou premier entré premier sorti en français) d'émission/réception 102 relié au 10 premier module d'interface 101, un module FIFO d'émission/réception 112 relié au second module d'interface 113, ainsi qu'un module FIFO d'émission/réception 105 permettant le transfert de données entre les modules aux premier 104 et second 111 modules de cryptage/décryptage. Le noeud 100 comprend : 15 un premier module 104 de cryptage/décryptage mettant en oeuvre des algorithmes de cryptage et décryptage conformes au protocole DTCP, et placé entre le module FIFO d'émission/réception 102 et le module FIFO d'émission/réception 105 ; - un second module 111 de cryptage/décryptage mettant en oeuvre des 20 algorithmes de cryptage et décryptage conformes au protocole DTCP, et placé entre lle module FIFO d'émission/réception 112 et le module FIFO d'émission/réception 105. Il comprend également un module de gestion de FIFO 103 permettant de contrôler les accès (en lecture et en écriture) aux modules FIFO 25 d'émission/réception 105, d'émission/réception 102 et d'émission/réception 112, conformément aux requêtes d'un module gestionnaire de pont 106. Il comprend également un module de contrôle DTCP 107 implémentant le protocole DTCP et relié aux premier 104 et second 111 modules de cryptage/décryptage. 30 Il comprend également : 2906097 18 - un microprocesseur 109 (ou CPU, pour Central Processing Unit en anglais) ; un bloc mémoire 110 (ou EPROM, pour Erasable Programmable Read Only Memory en anglais), relié au microprocesseur 109 ; 5 - un troisième module d'interface 108 avec le microprocesseur 109, relié au module de contrôle DTCP 107 et au module gestionnaire de pont 106. Avantageusement, tout noeud ou terminal du réseau domestique 1000 peut ne pas comprendre les modules de cryptage / décryptage précités (liés au cryptage et au décryptage DTCP) s'il ne participe pas respectivement aux cryptages et/ou 10 décryptages. On présente, en relation avec la figure 5, les étapes principales de procédés de mise à jour des listes de révocation SRM des dispositifs du réseau domestique 1000, basés sur des procédés d'échange de données sécurisé selon des premier et second modes de réalisation de l'invention. 15 Dans une étape 300, le réseau domestique 1000 est initialisé et, lors de cette initialisation, un noeud est élu comme noeud gestionnaire SRM pour le réseau 1000, dans la suite, on considère par exemple que le noeud 002 est élu comme noeud gestionnaire SRM. Cette élection peut être réalisée, par exemple : au moyen d'une configuration manuelle par un utilisateur du réseau ; 20 - au moyen d'un consentement mutuel entre les différents noeuds du réseau 1000 au moyen de la sélection du noeud présentant l'adresse IP la plus élevée. Selon une variante de ce mode de réalisation, plusieurs noeuds gestionnaires sont élus dans le réseau 1000. 25 Au cours de la phase d'attribution IP, dans une étape 301, le noeud gestionnaire SRM obtient au moins deux adresses IP, par exemple une première adresse IP et une seconde adresse IP. Pour ce faire, il peut par exemple demander, à un serveur conforme au protocole DHCP (pour Dynamic Host Configuration Protocol ) compris dans le 30 réseau 1000 (non illustré sur la figure 1), ces deux adresses IP. Mais il peut 2906097 19 également (selon un autre exemple) déclarer avoir un nombre de ports de sortie égal au nombre d'adresses dont il a besoin. La première adresse IP est dédiée aux transmissions et/ou réceptions (nécessitant la mise en oeuvre d'une adresse IP) de contenus de données selon le 5 procédé d'échange de données sécurisé conforme à l'invention entre le noeud gestionnaire SRM 002 et tout autre dispositif du réseau 1000. La seconde adresse IP est dédiée uniquement à la mise à jour des listes de révocation SRM des dispositifs du réseau 1000 au cours d'authentifications du procédé d'échange de données sécurisé conforme à l'invention dans le cadre 10 d'établissement de connexion sur cette seconde adresse IP tel qu'expliqué ci-après. Dans une étape 302, le noeud gestionnaire SRM attend que dans une étape 303 un nouveau dispositif conforme au procédé d'échange de données sécurisé selon l'invention (par exemple un dispositif conforme au protocole DTCP) soit 15 inséré au réseau domestique 1000. Si aucun nouveau dispositif conforme au procédé d'échange de données sécurisé selon l'invention n'est inséré dans le réseau 1000, alors l'étape 302 d'attente est remise en oeuvre. La détection par le noeud gestionnaire SRM 002 d'un tel nouveau 20 dispositif peut être effectuée grâce, par exemple, à un mécanisme de découverte de haut niveau tel que le protocole UPnP. Si un nouveau dispositif conforme au procédé d'échange de données sécurisé selon l'invention (par exemple le terminal 013) est détecté par le noeud gestionnaire SRM 002, alors dans une étape 304, ce dernier initialise une 25 connexion en mode protection contre la copie (i.e. en utilisant le procédé d'échange de données sécurisé conforme à l'invention) avec le nouveau dispositif 013 en utilisant sa première adresse IP. Ainsi, au cours de cette initialisation, dans une étape 305, une phase d'authentification et d'échange de clés conforme au procédé d'échange de 30 données sécurisé de l'invention (et également conforme au protocole DTCP) est 2906097 20 initialisée entre le noeud gestionnaire SRM 002 et le nouveau dispositif 013. De la même manière que pour le protocole DTCP (cf. figure 2), lors de cette phase d'authentification et d'échange de clés, dans une étape 306, le noeud gestionnaire SRM 002 et le nouveau dispositif 013 identifient mutuellement leur 5 numéro de version (autrement appelé statut SRM) de la liste de révocation SRM (étape 204 de la figure 2). De la même manière que pour le protocole DTCP (cf. figure 2), dans une étape 307, si le numéro de version de la liste SRM du nouveau dispositif 013 est plus ancien que le numéro de version de la liste SRM du noeud gestionnaire SRM 10 002, alors le noeud gestionnaire SRM 002 met à jour la liste SRM du nouveau dispositif 013 à l'aide de sa propre liste SRM, puis l'étape 302 est à nouveau mise en oeuvre. Si le numéro de version de la liste SRM du nouveau dispositif 013 est plus récent que le numéro de version de la liste SRM du noeud gestionnaire SRM 002, 15 alors le nouveau dispositif 013 met à jour la liste SRM du noeud gestionnaire SRM 002 à l'aide de sa propre liste SRM. Les étapes suivantes sont mises en oeuvre dans le cas où le numéro de version de la liste SRM du nouveau dispositif 013 (nouvelle liste de révocation) est plus récent que le numéro de version de la liste SRM du noeud gestionnaire 20 SRM 002. Puis, dans une étape 308, le noeud gestionnaire SRM 002 détecte, dans le réseau 1000, un dispositif cible, non à jour (dont le numéro de version de liste SRM est antérieur au numéro de version de la liste du noeud gestionnaire SRM 002 qui vient d'être mise à jour), par exemple le dispositif 012. 25 Puis, dans une étape 309, le noeud gestionnaire SRM 002 initialise une connexion en mode protection contre la copie avec ce dispositif non à jour 012 en utilisant sa seconde adresse IP. Il utilise sa seconde adresse IP pour cette authentification pour prévoir le cas, par exemple, où il se serait déjà authentifié avec le dispositif 012 dans le 30 cadre de l'établissement d'une connexion (encore valide) visant à permettre 2906097 21 l'échange d'un contenu entre le dispositif 012 et le noeud gestionnaire 002 (en effet, une seule adresse ne permet pas plusieurs authentifications simultanées). Ainsi, au cours de cette initialisation, dans une étape 310, une phase d'authentification et d'échange de clés conforme au procédé d'échange de 5 données sécurisé de l'invention (et également conforme au protocole DTCP) est initialisée entre le noeud gestionnaire SRM 002 et le dispositif non à jour 012 au cours de laquelle le noeud gestionnaire SRM 002 met à jour la liste SRM du dispositif non à jour 012. Dans une étape 311, le noeud gestionnaire SRM 002 contrôle s'il reste dans 10 le réseau 1000 au moins un autre dispositif non à jour (dont le numéro de version de liste SRM est antérieur au numéro de version de la liste du noeud gestionnaire SRM 002). Selon le premier mode de réalisation de l'invention, s'il reste dans le réseau 1000 au moins un autre dispositif non à jour, alors les étapes 308 à 311 15 sont remises en oeuvre par le dispositif gestionnaire SRM 002 pour chacun de ces dispositifs non à jour du réseau 1000. Selon le second mode de réalisation de l'invention, s'il reste dans le réseau 1000 au moins un autre dispositif non à jour, alors les étapes 308 à 311 sont remises en oeuvre par le dispositif gestionnaire SRM 002 pour seulement certains 20 de ces dispositifs non à jour du réseau 1000. Ensuite, les dispositifs mis à jour par le noeud gestionnaire SRM 002 mettent à leur tour à jour d'autres dispositifs non à jour et ainsi de suite. Ainsi, selon ce second mode de réalisation, la mise à jour des dispositifs non à jour du réseau 1000 est effectuée de proche en proche. Une fois que tous les dispositifs du réseau 1000 sont à jour (présentent un 25 numéro de version de liste SRM identique à celui du noeud gestionnaire SRM 002), alors l'étape 302 est remise en oeuvre. En conséquence, le procédé d'échange de données sécurisé selon l'invention se distingue du protocole DTCP essentiellement par le fait que ce procédé d'échange de données sécurisé de l'invention autorise la mise en oeuvre 30 d'au moins une seconde phase d'authentifications et d'échange de clés dans le 2906097 22 cadre de l'initialisation d'une seconde connexion alors qu'une première connexion, résultant d'une première phase d'authentifications et d'échange de clés, est encore active. En fonction

du type client ou serveur des dispositifs avec lesquels il établit 5 des connexions (par exemple le nouveau dispositif 013 ou le dispositif non à jour 012), le noeud gestionnaire SRM 002 doit se comporter alternativement comme un serveur ou un client. C'est pourquoi le noeud gestionnaire SRM 002 est préférentiellement un dispositif de type client/serveur. On illustre, en relation avec la figure 6, un algorithme d'établissement 10 d'une connexion HTTP, conforme au procédé d'échange de données sécurisé selon l'invention, entre le noeud gestionnaire SRM 002 (se comportant comme un client HTTP) et un dispositif serveur HTTP 500 (se comportant comme un serveur HTTP). Dans une première étape 501 d'initialisation du dispositif serveur 500 (qui 15 est par exemple un serveur WEB), le noeud gestionnaire SRM 002 (qui joue le rôle de contrôleur) indique, de manière classique, au dispositif serveur 500 notamment le nom de l'hôte et son adresse IP, le répertoire à partir duquel un contenu est à télécharger, la page WEB par défaut, des données de gestion de mot de passe (le cas échéant) et des algorithmes de prise en compte d'erreurs.

20 Par ailleurs, le noeud gestionnaire SRM 002 transmet au dispositif serveur 500, un algorithme de rappel qui est mis en oeuvre par le dispositif serveur 500 avant d'envoyer un contenu à un client. En effet, cet algorithme lui permet d'effectuer des traitements spécifiques sur le contenu tel que, par exemple, le traitement spécifique au protocole DTCP-IP (qui consiste en l'adaptation de 25 l'entête HTTP avec le type de contenu approprié, l'insertion d'entêtes PCP et la réalisation du cryptage AES-128/CBC du contenu). Dans une seconde étape 502, le contrôleur appelle l'interface de programmation (ou Application Programming Interface en anglais) appelée DTCP_OpenServerSession du dispositif serveur 500 qui permet d'ouvrir une 30 session serveur conforme au protocole DTCP. En particulier, cette interface de 2906097 23 programmation crée un serveur d'authentification qui attend, en écoutant sur le port TCP dédié aux authentifications DTCP-IP, les connexions client avant de les accepter (le cas échéant). Cet appel (étape 502) de l'interface de programmation permet d'obtenir le 5 nom d'hôte et le numéro de port utilisés pour l'authentification DTCP-IP. Ainsi, ces nom d'hôte (ou host name en anglais) et numéro de port (ou port number en anglais) peuvent être utilisés pour la construction des adresses URL telles que, par exemple l'adresse suivante : http:/hostname/path/filename.type ?CONTENTPROTECTION=DTCP1&DTCP 10 1HOST=hostname&DTCP1PORT=portnum qui est conforme au protocole DTCP-IP et qui permet de présenter le nom d'hôte et le numéro de port au client. Dans une troisième étape 503, le contrôleur appelle l'interface de programmation appelée DTCP_AddServerStream du dispositif serveur 500. Cette interface de programmation permet d'ajouter un flux correspondant à un 15 contenu dans une session de serveur préalablement créée, associant ce flux au E- EMI qui doit être utilisé pour ce contenu. On rappelle que l'E-EMI définit le niveau de protection contre la copie associé à un flux protégé par un protocole DTCP. Dans le cas du protocole DTCP-IP, sept niveaux de protection sont ainsi 20 définis (incluant un niveau copie libre ). Dans le cas du protocole DTCP-1394, quatre niveaux de protection sont ainsi définis (incluant un niveau copie libre ). Il est possible d'ajouter plusieurs flux différents (par exemple associés à différents E-EMIs), dans une unique session serveur.

25 On illustre, en relation avec la figure 7, un algorithme d'établissement d'une connexion HTTP entre le noeud gestionnaire SRM 002 (se comportant comme un serveur HTTP) et un dispositif client HTTP 600 (se comportant comme un client HTTP) conforme au procédé d'échange de données sécurisé selon l'invention.

30 Dans une première étape 601, le noeud gestionnaire SRM 002 (qui joue le 2906097 24 rôle de contrôleur) transmet au dispositif client HTTP 600 une adresse URL à ouvrir. Puis dans une étape 602, le dispositif client HTTP 600 analyse cette adresse URL afin de vérifier si elle se réfère à un contenu protégé au moyen du protocole DTCP-IP. Si c'est le cas (c'est-à-dire que le contenu présente une forme 5 conforme au protocole DTCP-IP), le dispositif client 600 extrait, de l'adresse URL, le nom d'hôte et le numéro de port liés à l'authentification DTCP-IP. Dans une seconde étape 603, le contrôleur appelle l'interface de programmation appelée DTCP_OpenClientSession du dispositif client 600. Cette interface de programmation permet d'ouvrir une session client conforme au 10 protocole DTCP-IP associée au serveur HTTP (noeud gestionnaire SRM 002) avec le nom d'hôte obtenu. En particulier, cette interface de programmation ouvre une connexion TCP d'authentification avec les nom d'hôte et numéro de port obtenus et initie la phase d'authentification conforme au protocole DTCP-IP. Tel qu'indiqué ci-dessus, en relation avec la figure 2, cette phase d'authentification 15 permet au dispositif client d'obtenir, auprès du serveur, une clé d'authentification et une clé d'échange et permet également de mettre à jour la liste SRM du serveur ou celle du client en fonction de la génération et/ou du numéro de version de leurs listes SRM. Dans une troisième étape 604, le contrôleur appelle l'interface de 20 programmation appelée DTCP_AddClientStream du dispositif client 600. Cette interface de programmation permet d'ajouter un flux correspondant à un contenu identifié par son adresse URL dans une session de client préalablement créée. Dans le cas où un client doit récupérer plusieurs contenus protégés conformément au protocole DTCP-IP sur le même serveur, il est possible 25 d'ajouter plusieurs flux différents dans une unique session de client. Cet appel (étape 604) de l'interface de programmation permet au client HTTP d'associer le contenu à la clé d'échange appropriée obtenue pendant la phase d'authentification. Puis, classiquement, le contrôleur appelle une ouverture de connexion TCP 30 avec une interface réseau 6000 pour le contenu HTTP (étape 605), un envoi de la 2906097 25 requête HTTP obtenue (étape 606), une récupération de la réponse (étape 607) et une analyse du contenu de réponse (étape 608). Le protocole HTTP est explicité dans le document de référence intitulé RFC 2616, Hypertext Transfer Protocol ù http/1.1 .

5 On se place maintenant dans le cadre du réseau de communication de la figure 3. Afin d'obtenir la configuration suivante : le noeud client 403 puisse accéder à un contenu c (et que cet accès soit restreint au noeud client 403) disponible, via le noeud adaptateur 400, sur le 10 noeud serveur 407 ; tout en interdisant, par exemple, aux noeuds clients 401 et 402 d'accéder audit contenu c, une solution est la mise en oeuvre du procédé d'échange de données sécurisé selon un mode de réalisation de l'invention.

15 En effet, afin d'obtenir la configuration précitée, une solution est que le noeud adaptateur 400 obtienne au moins deux adresses réseau (adresses IP dans le cas où les liens du réseau de la figure 3 sont des liens Ethernet). L'une de ces adresses réseau (aussi appelée adresse publique) est utilisée par le noeud adaptateur 400 pour les phases d'authentification et d'échange de clé 20 DTCP pour la transmission de contenu dont l'accès est non restreint. Elle est associée à des clés de cryptage publiques. Une autre adresse de ces adresses réseau (aussi appelée adresse privée) est utilisée par le noeud adaptateur 400 pour les phases d'authentification et d'échange de clé DTCP pour la transmission de contenu dont l'accès est restreint.

25 Elle est associée à des clés de cryptage privées. Ainsi, une connexion pour la transmission, conformément au procédé d'échange de données sécurisé selon l'invention, du contenu c, dont l'accès est restreint au noeud client 403, est établit (tel que décrit en relation avec les figures 6 et 7) entre le noeud adaptateur 400 et le noeud client 403 grâce à l'adresse privée.

30 Ceci conduit à la génération et à l'échange d'une clé de cryptage provée Kcl 2906097 26 uniquement partagée par les noeuds client 403 et adaptateur 400. Ainsi, le contenu c crypté par le noeud adaptateur 400 au moyen de la clé de cryptage privée Kcl n'est accessible que pour le noeud client 403 alors que le noeud client 403 est quand même capable de recevoir et de décrypter des contenus 5 préalablement cryptés au moyen de clés publiques. On présente, en relation avec la figure 8, les étapes principales d'un procédé d'échange de données sécurisé du contenu c à accès restreint du noeud serveur 407 au noeud client 403 dans le réseau de la figure 3 selon un troisième mode de réalisation de l'invention.

10 Dans une étape 500, le réseau de communication de la figure 3 est initialisé. Au cours de la phase d'attribution IP, dans une étape 501, le noeud adaptateur 400 demande et obtient au moins deux adresses IP, par exemple une première adresse IP et une seconde adresse IP.

15 Pour ce faire, il peut par exemple demander, à un serveur conforme au protocole DHCP (pour Dynamic Host Configuration Protocol ) compris dans le réseau de communication (non illustré sur la figure 3), ces deux adresses IP. Mais il peut également (selon un autre exemple) déclarer avoir un nombre de ports de sortie égal au nombre d'adresses dont il a besoin.

20 La première adresse IP (également appelée adresse publique) est dédiée aux transmissions et/ou réceptions (nécessitant la mise en oeuvre d'une adresse IP) de contenus de données entre le noeud adaptateur 400 et tout autre dispositif du réseau de la figure 3 mais également pour des accès non retreints d'un ou plusieurs noeuds client(s) à des contenus stockés sur le noeud serveur 407.

25 La seconde adresse IP (également appelée adresse privée) est dédiée uniquement à des accès restreints à un ou plusieurs noeuds client(s) à des contenus stockés sur le noeud serveur 407 (tel que le contenu c cité en relation avec la figure 7). Dans une étape 502, le noeud adaptateur 400 attend, que dans une étape 30 503, un noeud client conforme au protocole DTCP requière l'accès à un contenu 2906097 27 stocké sur le noeud serveur 407. Si aucune requête d'accès à un contenu stocké sur le noeud serveur 407 n'est reçue par le noeud adaptateur 400, alors l'étape 502 d'attente est remise en oeuvre.

5 Si une requête d'accès à un contenu stocké sur le noeud serveur 407 est reçue par le noeud adaptateur 400, alors dans une étape 504, ce dernier vérifie si la requête est une requête en accès restreint au contenu ou pas. Si la requête est une requête en accès restreint au contenu, alors dans une étape 506, le noeud adaptateur 400 utilise l'adresse privée pour mettre en oeuvre 10 une phase d'authentification et d'échange de clé DTCP avec le noeud requérant. Si la requête n'est pas une requête en accès restreint au contenu, alors dans une étape 505, le noeud adaptateur 400 utilise l'adresse publique pour mettre en oeuvre une phase d'authentification et d'échange de clé DTCP avec le noeud requérant.

15 Ainsi, l'utilisation de ces deux adresses publique et privée conduit à la mise en oeuvre d'au moins une clé publique et d'au moins une clé privée qui sont distinctes, ce qui assure qu'un contenu auquel un accès en mode retreint est demandé par le noeud client 403 ne peut pas être lu par un autre noeud client authentifié.

20 Puis, dans une étape 507, le noeud adaptateur 400 initialise une connexion en mode protection contre la copie (i.e. en utilisant le procédé d'échange de données sécurisé conforme à l'invention) entre le noeud requérant et le noeud adaptateur 400 (les figures 6 et 7 précédemment décrites illustrent l'établissement d'une telle connexion).

25 Dans une étape 508, une phase d'authentification et d'échange de clé DTCP est mise en oeuvre entre le noeud requérant et le noeud adaptateur 400 avec l'adresse IP obtenue dans les étapes 505 ou 506. 30

Claims

REVENDICATIONS

1. Procédé d'échange de données sécurisé entre un premier dispositif (002) et second dispositif dans un réseau de communication (1000) comprenant une pluralité de dispositifs (010, 011, 012, 013, 014, 015, 000, 001, 002, 003 ; 400, 401, 402, 403, 407), lesdits premier et second dispositifs utilisant un protocole de protection de contenu comprenant une première authentification dans le cadre de l'initialisation d'une première connexion entre au moins les premier et second dispositifs, caractérisé en ce qu'il comprend les étapes suivantes mises en oeuvre par le premier dispositif : détection d'un événement pour échanger au moins une information complémentaire ; seconde authentification (310 ; 508) avec le second dispositif dans le cadre de l'initialisation d'une seconde connexion pour échanger ladite information complémentaire, la première connexion étant active, ladite seconde authentification étant mise en oeuvre après la détection dudit événement.

2. Procédé selon la revendication 1, caractérisé en ce que les première et seconde connexions sont respectivement associées à des première et seconde adresses du premier dispositif (002), ladite première adresse étant distincte de ladite seconde adresse.

3. Procédé selon la revendication 2, caractérisé en ce que les première et seconde adresses sont associées à des premier et second ports de sortie du premier dispositif (002).

4. Procédé selon l'une quelconque des revendications 2 à 3, caractérisé en ce que les première et seconde adresses sont obtenues (301 ; 501) auprès d'un serveur d'adresses compris dans le réseau de communication.

5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que le protocole de protection de contenu est le protocole DTCP-IP.

6. Procédé selon l'une quelconque des revendications 1 à 5, lesdits premier et 2906097 29 second dispositifs comprenant une liste de révocation associée au protocole de protection de contenu, caractérisé en ce que l'événement détecté est une différence entre les listes de révocation desdits premier et second dispositifs et en ce que l'information complémentaire est la liste de révocation la plus récente. 5

7. Procédé selon la revendication 6, caractérisé en ce qu'il comprend les étapes suivantes mises en oeuvre par le premier dispositif pour au moins le second dispositif : détermination si la liste de révocation du second dispositif est antérieure à la liste de révocation du premier dispositif (002) ; 10 - si la liste de révocation du second dispositif est antérieure à la liste de révocation du premier dispositif, mise à jour (310) de la liste de révocation du second dispositif au moyen de la liste de révocation du premier dispositif.

8. Procédé selon l'une quelconque des revendications 6 à 7, caractérisé en ce 15 qu'il comprend au préalable les étapes suivantes : - réception (305) d'une liste de révocation d'un troisième dispositif du réseau de communication ; - mise à jour (307) de la liste de révocation du premier dispositif (002) avec la liste de révocation reçue. 20

9. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que l'événement détecté est une requête d'échange d'un contenu privé entre le premier dispositif et le second dispositif et en ce que l'information complémentaire comprend des paramètres de clé de cryptage correspondants à la seconde connexion. 25

10. Procédé d'échange de données sécurisé entre un premier dispositif et second dispositif (002) dans un réseau de communication (1000) comprenant une pluralité de dispositifs (010, 011, 012, 013, 014, 015, 000, 001, 002, 003 ; 400, 401, 402, 403, 407), lesdits premier et second dispositifs utilisant un protocole de protection de contenu comprenant une première authentification dans le cadre de 30 l'initialisation d'une première connexion entre au moins les premier et second 2906097 30 dispositifs, caractérisé en ce qu'il comprend l'étape suivante mise en oeuvre par le premier dispositif : seconde authentification (310 ; 508) avec le second dispositif dans le cadre 5 de l'initialisation d'une seconde connexion pour échanger au moins une information complémentaire, la première connexion étant active, ladite seconde authentification étant mise en oeuvre après la détection dudit événement.

11. Procédé selon la revendication 10, caractérisé en ce que le protocole de 10 protection de contenu est le protocole DTCP-IP.

12. Produit programme d'ordinateur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution des étapes des procédés d'échange selon l'une quelconque des revendications 1 à 9 et/ou selon l'une quelconque des revendications 10 et 1l, lorsque ledit programme est exécuté sur 15 un ordinateur.

13. Moyen de stockage lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre les procédés d'échange selon l'une quelconque des revendications 1 à 9 et/ou selon l'une quelconque des revendications 10 et 11. 20

14. Premier dispositif (002) comprenant des moyens d'échange de données sécurisé avec un second dispositif, lesdits premier et second dispositifs appartenant à un réseau de communication (1000) comprenant une pluralité de dispositifs (010, 011, 012, 013, 014, 015, 000, 001, 002, 003 ; 400, 401, 402, 403, 407), lesdits moyens d'échange comprenant des premiers moyens d'initialisation, 25 permettant d'initialiser une première connexion entre le premier dispositif et au moins le second dispositif conformément à un protocole de protection de contenu, lesdits premiers moyens d'initialisation comprenant des premiers moyens d'authentification du premier dispositif avec le second dispositif conformément au protocole de protection de contenu, 30 caractérisé en ce que les moyens d'échange comprennent : 2906097 31 des moyens de détection d'un événement pour échanger au moins une information complémentaire ; des seconds moyens d'initialisation, permettant d'initialiser une seconde connexion entre le premier dispositif et le second dispositif conformément 5 au protocole de protection de contenu pour échanger ladite information complémentaire, lesdits seconds moyens d'initialisation comprenant des seconds moyens d'authentification du premier dispositif avec le second dispositif conformément au protocole de protection de contenu ; des moyens d'activation des seconds moyens d'initialisation qui active les 10 seconds moyens d'initialisation si la première connexion est active et si l'événement est détectée.

15. Premier dispositif selon la revendication 14, caractérisé en ce que les première et seconde connexions sont respectivement associées à des première et seconde adresses du premier dispositif (002), ladite première adresse étant 15 distincte de ladite seconde adresse.

16. Premier dispositif selon la revendication 15, caractérisé en ce que les première et seconde adresses sont associées à des premier et second ports de sortie du premier dispositif (002).

17. Premier dispositif selon l'une quelconque des revendications 14 à 16, 20 caractérisé en ce qu'il comprend des moyens d'obtention des première et seconde adresses auprès d'un serveur d'adresses compris dans le réseau de communication (1000).

18. Premier dispositif selon l'une quelconque des revendications 14 à 17, caractérisé en ce que le protocole de protection de contenu est le protocole DTCP-25 IP.

19. Premier dispositif selon l'une quelconque des revendications 14 à 18, lesdits premier et second dispositifs comprenant une liste de révocation associée au protocole de protection de contenu, caractérisé en ce que l'événement détecté est une différence entre les listes de révocation desdits premier dispositif (002) et 30 second dispositif et en ce que l'information complémentaire est la liste de 2906097 32 révocation la plus récente.

20. Premier dispositif selon la revendication 19, caractérisé en ce qu'il comprend : des moyens de détermination si la liste de révocation du second dispositif 5 est antérieure à la liste de révocation du premier dispositif (002) ; des moyens de mise à jour de la liste de révocation du second dispositif au moyen de la liste de révocation du premier dispositif, lesdits moyens de mise à jour étant activés si la liste de révocation du second dispositif est antérieure à la liste de révocation du premier dispositif. 10

21. Premier dispositif selon l'une quelconque des revendications 19 à 20, caractérisé en ce qu'il comprend : - des moyens de réception d'une liste de révocation d'un troisième dispositif du réseau de communication - des moyens de mise à jour de la liste de révocation du premier dispositif 15 (002) avec la liste de révocation reçue.

22. Premier dispositif selon l'une quelconque des revendications 14 à 18, caractérisé en ce que l'événement détecté est une requête d'échange d'un contenu privé entre le premier dispositif et le second dispositif et en ce que l'information complémentaire comprend des paramètres de clé de cryptage correspondants à la 20 seconde connexion.

23. Premier dispositif comprenant des moyens d'échange de données sécurisé avec un second dispositif, lesdits premier et second dispositifs appartenant à un réseau de communication (1000) comprenant une pluralité de dispositifs (010, 011, 012, 013, 014, 015, 000, 001, 002, 003 ; 400, 401, 402, 403, 407), lesdits 25 moyens d'échange comprenant des premiers moyens d'initialisation permettant d'initialiser une première connexion entre le premier dispositif et au moins le second dispositif conformément à un protocole de protection de contenu, lesdits premiers moyens d'initialisation comprenant des premiers moyens d'authentification du premier dispositif avec le second dispositif conformément au 30 protocole de protection de contenu, 2906097 33 caractérisé en ce que les moyens d'échange comprennent : des seconds moyens d'initialisation permettant d'initialiser une seconde connexion entre le premier dispositif et le second dispositif conformément au protocole de protection de contenu pour échanger au moins une 5 information complémentaire, lesdits seconds moyens d'initialisation comprenant des seconds moyens d'authentification du premier dispositif avec le second dispositif conformément au protocole de protection de contenu ; des moyens d'activation des seconds moyens d'initialisation qui active les 10 seconds moyens d'initialisation si la première connexion est active.

24. Premier dispositif selon la revendication 23, caractérisé en ce que le protocole de protection de contenu est le protocole DTCP-IP.