FR2886081A1 - Procede d'echange de paquets de donnees dans un reseau de communication, produit programme d'ordinateur, moyen de stockage et noeuds correspondants - Google Patents

Procede d'echange de paquets de donnees dans un reseau de communication, produit programme d'ordinateur, moyen de stockage et noeuds correspondants Download PDF

Info

Publication number
FR2886081A1
FR2886081A1 FR0504943A FR0504943A FR2886081A1 FR 2886081 A1 FR2886081 A1 FR 2886081A1 FR 0504943 A FR0504943 A FR 0504943A FR 0504943 A FR0504943 A FR 0504943A FR 2886081 A1 FR2886081 A1 FR 2886081A1
Authority
FR
France
Prior art keywords
node
authentication
encryption key
parameters
source
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0504943A
Other languages
English (en)
Other versions
FR2886081B1 (fr
Inventor
Pascal Lagrange
Stephane Bizet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to FR0504943A priority Critical patent/FR2886081B1/fr
Publication of FR2886081A1 publication Critical patent/FR2886081A1/fr
Application granted granted Critical
Publication of FR2886081B1 publication Critical patent/FR2886081B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0464—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload using hop-by-hop encryption, i.e. wherein an intermediate entity decrypts the information and re-encrypts it before forwarding it
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2107—File encryption
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2129—Authenticate client device independently of the user

Abstract

L'invention concerne un procédé d'échange de paquets de données dans un réseau de communication entre un dispositif source (006) lié à un noeud source (003) et un dispositif récepteur (009) lié à un noeud récepteur (004), les paquets de données provenant du dispositif source (006) étant cryptés selon une première clé de cryptage.le noeud récepteur (004) :- réception d'une requête d'authentification conforme à une phase d'authentification selon un protocole de protection de contenu, provenant du dispositif récepteur (009) ;- transmission de la requête d'authentification à un noeud d'authentification (0051) du réseau de communication, mettant en oeuvre la phase d'authentification selon le protocole de protection de contenu, en vue de la mise en oeuvre d'une authentification du dispositif récepteur (009) par le noeud d'authentification (0051) ;réception de paramètres permettant d'obtenir une seconde clé de cryptage et transmission de ces paramètres au dispositif récepteur (009) ;- transmission au dispositif récepteur (009) de paquets de données préalablement décryptés, avec la première clé de cryptage, et cryptés selon la seconde clé de cryptage, par un noeud de transcription (0052) mettant en oeuvre une phase de cryptage/décryptage selon le protocole de protection de contenu.

Description

Procédé d'échange de paquets de données dans un réseau de communication, produit programme d'ordinateur, moyen de stockage et n u̇ds 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 isochrones transmises entre plusieurs dispositifs terminaux dans un tel réseau.
On connaît, en effet, aujourd'hui des réseaux de communication auxquels sont connectés différents appareils générant et/ou recevant des contenus de données isochrones, ainsi que des unités de stockage de ces contenus (disques durs externes par exemple).
L'invention s'applique notamment, mais non exclusivement, dans le cas d'un réseau multimédia, où le flux de données isochrone 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 n u̇ds. Aux n u̇ds sont reliés des équipements, directement via des liens analogiques ou indirectement, par exemple, via des bus numériques séries conformes à la norme IEEE-1394. On rappelle que cette dernière est décrite dans les documents de référence suivants : IEEE Std 1394-1995, Standard for High Performance Sériai Bus , IEEE Std 1394a-2000, Standard for High Performance Sériai Bus (Supplément) et IEEE P1394.1 Draft 0.15, Standard for High Performance Sériai Bus Bridges .
La figure 1A illustre un exemple d'un tel réseau audio-vidéo domestique 1000. Ce réseau domestique 1000 comprend un réseau fédérateur 1001 comprenant lui-même des n u̇ds 003, 004, 0051, 0052 interconnectés via une unité centrale de commutation 015, dont un schéma est présenté en figure IB.
L'unité centrale de commutation 015 comprend plusieurs dispositifs de commutation dont notamment un dispositif de commutation 150a. Ce même dispositif de commutation 150a est relié à 3 autres dispositifs de commutation référencés 150b, 150c et 150d. Par simplicité, on a représenté sur la figure 1B une telle unité de commutation 015 ne comprenant que 4 dispositifs de commutation.
Le dispositif de commutation 150a est relié par l'intermédiaire d'un câble 153a au dispositif de commutation 150d, il est aussi relié par l'intermédiaire d'un autre câble 153d au dispositif de commutation 150c qui est lui-même relié par un autre lien 153e au dispositif de commutation 150d.
Le dispositif de commutation 150c est relié au dispositif de commutation 150b par l'intermédiaire de liaison 153c et finalement le dispositif de commutation 150b est relié au dispositif de commutation 150a par intermédiaire d'un lien de communication 153b.
Il est à remarquer que les dispositifs de commutation 150a, 150b, 150c et 150d sont insérés dans les cloisons d'une habitation. Ils peuvent cependant être indépendants des cloisons et être ainsi déplaçables.
Le dispositif 150a est par exemple placé dans la cloison 152a d'une pièce telle qu'une salle de séjour, le dispositif 150b dans la cloison 152b d'une autre pièce telle que la cuisine et le dispositif 150c dans la cloison 120c d'une pièce telle qu'un bureau, le dispositif 150d dans la cloison 152d d'une chambre.
Les dispositifs de commutation 150a, 150b, 150c et 150d sont reliés à des n u̇ds 003, 004, 0051 et 0052 du réseau fédérateur 1001 par l'intermédiaire d'un unique médium, dans notre cas des câbles 151a, 151b, 151c et 151d.
Le n u̇d 003 est aussi connecté à des dispositifs terminaux :
un téléviseur 014, un lecteur DVD 013 et un magnétoscope VHS 012 au moyen de liens analogique ; à un disque dur audio-vidéo 006, un magnétoscope VHS numérique 007 et un lecteur DVD numérique IEEE-1394 008 au moyen d'un bus série numérique IEEE-1394 001.
Le n u̇d 004 est connecté via un bus série numérique IEEE-1394 002 à un téléviseur numérique 009, un magnétoscope VHS numérique 010 et un tuner IEEE-1394 011.
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 domestique tel que celui de la figure 1A est la mise en u̇vre 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 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 est un diagramme illustrant la mise en oeuvre du protocole DTCP en cascade dans un réseau générique 20 comprenant deux n u̇ds 204 et 205. Il est bien entendu que ce protocole DTCP en cascade, mis en oeuvre ici par soucis de simplicité dans un réseau générique peut aussi être mis en u̇vre dans le réseau domestique 1000 de la figure lA.
Les n u̇ds 204 et 205 sont interconnectés au moyen d'un bus série IEEE1394 201. Le n u̇d 204 est aussi connecté à un dispositif émetteur 203 au moyen d'un bus série IEEE-1394 200, de même que le n u̇d 205 est connecté à un dispositif récepteur 206 au moyen d'un bus série IEEE-1394 202.
Lorsque le dispositif émetteur 203 transmet un flux de données crypté 209, crypté au moyen de sa propre clé de cryptage (notée key (N#X) sur la figure 2), dans le réseau générique 20, il met en u̇vre le format de paquets isochrones IEEE-1394 combiné avec les recommandations DTCP.
Lorsque le dispositif récepteur 206 souhaite recevoir un flux de données, il doit tout d'abord vérifier si ce flux est protégé contre la copie (voir la définition des bits EMI dans Digital Transmission Content Protection Specification, Volume 1 et 2, Draft 1.29 ). Puis, si le flux est protégé contre la copie, le dispositif récepteur 206 doit s'authentifier auprès du n u̇d 205 au moyen d'un procédé d'authentification DTCP comprenant l'émission d'une requête d'authentification 214 à laquelle succède une réponse 215 provenant du n u̇d 205. Une fois que ce procédé d'authentification DTCP est réalisé avec succès, le n u̇d 205 met en u̇vre le même procédé d'authentification avec le n u̇d 204.Une fois que ce procédé d'authentification DTCP est réalisé avec succès, le n u̇d 204 met en u̇vre le même procédé d'authentification DTCP avec le dispositif émetteur 203. Une fois que ce dernier procédé d'authentification DTCP est réalisé avec succès, le dispositif récepteur 206 peut décrypter le flux protégé.
Ainsi, pour chaque flux de données à transmettre, ce protocole DTCP en cascade nécessite la mise en u̇vre d'un cryptage du flux de données, d'un procédé d'authentification DTCP puis d'un décryptage et ceci à chaque transmission depuis un dispositif ou n u̇d du réseau vers un autre dispositif ou n u̇d du réseau. Il conduit donc à la mise en u̇vre d'une grande quantité d'étapes gérées par un ou plusieurs logiciels et donc à une surcharge du réseau dans lequel il est mis en u̇vre et à un temps de transmission des flux de données important.
D'autre part, la mise en u̇vre du protocole DTCP dans un réseau de communication tel que le réseau domestique de la figure 1A nécessite que chacun des n u̇ds et des dispositifs terminaux du réseau soient compatible avec ce protocole. Ainsi, chacun des n u̇ds et terminaux du réseau doit implémenter les composants physiques (module de cryptage / de décryptage, ...) et les logiciels adaptés pour la mise en u̇vre du protocole DTCP, ce qui représente un coût et un encombrement important pour la mise en oeuvre du réseau.
3. Objectifs de l'invention L'invention a notamment 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 modes de réalisation, est de fournir une technique d'échange de données protégées contre la copie dans un réseau de communication domestique comprenant des liens analogiques et des liens numériques, la protection contre la copie étant transparente pour les terminaux, et ceci en limitant la charge du réseau liée à cette protection.
Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de mettre en u̇vre une telle technique qui permette de réduire le temps de transmission des flux de données dans un tel réseau.
Encore un objectif de l'invention, dans au moins un de ses modes de réalisation, est de mettre u̇vre une telle technique qui ne nécessite pas que chacun des n u̇ds et des dispositifs terminaux du réseau soit compatible à un protocole de protection de contenu prédéterminé.
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 u̇vre 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 paquets de données dans un réseau de communication entre un dispositif source lié à un n u̇d source et un dispositif récepteur lié à un n u̇d récepteur, les paquets de données provenant du dispositif source étant cryptés selon une première clé de cryptage.
Selon l'invention, un tel procédé comporte les étapes suivantes mises en u̇vre par le n u̇d récepteur :
réception d'une requête d'authentification conforme à une phase d'authentification selon un protocole de protection de contenu, provenant du dispositif récepteur ; transmission de la requête d'authentification à un n u̇d d'authentification du réseau de communication, mettant en u̇vre la phase d'authentification selon le protocole de protection de contenu, en vue de la mise en u̇vre d'une authentification du dispositif récepteur par le n u̇d d'authentification ; réception de paramètres permettant d'obtenir une seconde clé de cryptage et transmission de ces paramètres au dispositif récepteur ;transmission au dispositif récepteur de paquets de données préalablement décryptés, avec la première clé de cryptage, et cryptés selon la seconde clé de cryptage, par un n u̇d de transcription mettant en u̇vre une phase de cryptage/décryptage selon le protocole de protection de contenu.
Ainsi, l'invention propose un procédé d'échange de données dans un réseau mettant en u̇vre un protocole de protection de contenu, dont les étapes de cryptage / décryptage (appelées ci-après de transcription) et d'authentification du protocole de protection de contenu sont centralisées respectivement dans un n u̇d de transcription et dans un n u̇d d'authentification du réseau.
De ce fait, les autres noeuds d'un tel réseau n'ont pas besoin d'être compatible avec le protocole de protection de contenu. On économise en conséquence l'implémentation des composants et logiciels permettant la transcription et/ou l'authentification au niveau des n u̇ds qui ne sont pas le n u̇d de transcription et/ou d'authentification. Ceci permet ainsi de réduire les coûts et encombrement de tels réseaux.
Par ailleurs, le procédé d'échange de données selon l'invention permet de limiter la charge du réseau liée à la protection de contenu ainsi que le temps de transmission des flux de données.
Préférentiellement, la mise en u̇vre de l'authentification du dispositif récepteur s'effectue par le transfert d'au moins deux requêtes d'authentification entre le dispositif récepteur et le n u̇d d'authentification.
Ainsi, par exemple lorsque l'on met en u̇vre le protocole DTCP, plusieurs requêtes d'authentification sont utilisées.
Avantageusement, la transmission de la ou des requêtes d'authentification à un n u̇d d'authentification se fait par l'intermédiaire du n u̇d de transcription.
Selon un mode de mise en u̇vre préférentiel conforme à l'invention, le n u̇d récepteur est distinct du n u̇d de transcription et les paramètres permettant d'obtenir une seconde clé de cryptage sont des paramètres introduits par le n u̇d de transcription et reçus de ce dit n u̇d.
Selon un autre mode de mise en u̇vre préférentiel conforme à l'invention, le n u̇d récepteur et le n u̇d de transcription sont confondus, et l'étape de réception de paramètres permettant d'obtenir une seconde clé de cryptage comprend une étape de substitution de paramètres initialement reçus du n u̇d d'authentification.
Ainsi, le n u̇d récepteur jouant le rôle de n u̇d de transcription, on s'affranchit de la mise en u̇vre d'un n u̇d supplémentaire pour jouer ce rôle, ce qui permet de réaliser des économies en termes de coût et d'encombrement.
Avantageusement, le procédé selon l'invention comprend en outre une étape de réception en provenance du n u̇d d'authentification de paramètres permettant d'obtenir la première clé de cryptage.
Préférentiellement, l'étape de réception de paramètres permettant d'obtenir une seconde clé de cryptage consiste en une étape de réception de la seconde clé de cryptage envoyée par le n u̇d d'authentification.
On peut ainsi observer une transmission de la seconde clé de cryptage en tant que telle.
Avantageusement, le n u̇d récepteur et le n u̇d de transcription sont confondus et le procédé comprend en outre une étape de réception en provenance du n u̇d d'authentification de la première clé de cryptage.
Selon un mode de réalisation avantageux conforme à l'invention, le n u̇d récepteur est distinct du n u̇d d'authentification.
Selon un autre mode de réalisation avantageux conforme à l'invention, le n u̇d récepteur et le n u̇d d'authentification sont confondus.
Selon une caractéristique avantageuse de l'invention, le protocole de protection de contenu est le protocole DTCP.
Ce protocole peut cependant être tout autre protocole de protection de contenus.
L'invention concerne également un procédé d'échange de paquets de données dans un réseau de communication entre un dispositif source lié à un n u̇d source et un dispositif récepteur lié à un n u̇d récepteur, les paquets de données provenant du dispositif source étant cryptés selon une première clé de cryptage, le procédé comportant les étapes suivantes mises en u̇vre par le n u̇d source : - réception d'une requête d'authentification conforme à une phase d'authentification selon un protocole de protection de contenu, provenant d'un n u̇d d'authentification ; - transmission de la requête d'authentification au dispositif source, en vue de la mise en u̇vre d'une authentification du n u̇d d'authentification par le dispositif source ;- réception de paramètres permettant d'obtenir la première clé de cryptage du dispositif source et transmission de ces paramètres au n u̇d d'authentification ; - réception des paquets de données cryptés avec la première clé de cryptage provenant du dispositif source ; - transmission à un n u̇d de transcription mettant en u̇vre une phase de cryptage/décryptage selon le protocole de protection de contenu des paquets de données cryptés avec la première clé de cryptage afin qu'il puisse décrypter lesdites données au moyen de la première clé et ensuite les crypter au moyen d'une seconde clé de cryptage.
Avantageusement, la mise en u̇vre de l'authentification du n u̇d d'authentification s'effectue par le transfert d'au moins deux requêtes d'authentification entre le dispositif source et le n u̇d d'authentification.
Ainsi, par exemple lorsque l'on met en u̇vre le protocole DTCP, plusieurs requêtes d'authentification sont utilisées.
Préférentiellement, l'étape de transmission au n u̇d d'authentification de paramètres permettant d'obtenir la première clé dé cryptage se fait par l'intermédiaire du n u̇d de transcription.
Selon une caractéristique avantageuse de l'invention, l'étape de transmission au n u̇d d'authentification de paramètres permettant d'obtenir la première clé de cryptage consiste en une étape de transmission au n u̇d d'authentification de la première clé de cryptage.
Selon un mode de mise en u̇vre avantageux de l'invention, le n u̇d source est distinct du n u̇d de transcription.
Selon un autre mode de mise en u̇vre avantageux de l'invention, le n u̇d source et le n u̇d de transcription sont confondus et le procédé comprend en outre :
une étape de transmission au dispositif récepteur via le n u̇d récepteur de paramètres permettant d'obtenir la seconde clé de cryptage après substitution de paramètres initialement reçus du n u̇d d'authentification ; une étape de transmission au dispositif récepteur via le n u̇d récepteur des données cryptées avec la seconde clé.
Selon un mode de réalisation avantageux de l'invention, le n u̇d source est distinct du n u̇d d'authentification.
Selon un autre mode de réalisation avantageux de l'invention, le n u̇d source et le n u̇d d'authentification sont confondus.
Préférentiellement, le protocole de protection de contenu est le protocole DTCP.
L'invention concerne également un procédé d'échange de paquets de données dans un réseau de communication entre un dispositif source lié à un n u̇d source et un dispositif récepteur lié au n u̇d récepteur les paquets de données provenant du dispositif source étant cryptés selon une première clé de cryptage, le procédé comportant les étapes suivantes mises en u̇vre par un n u̇d d'authentification : - mise en u̇vre d'une phase d'authentification selon un protocole de protection de contenu afin d'authentifier le dispositif récepteur via le n u̇d récepteur ; - transmission de paramètres permettant d'obtenir une seconde clé de cryptage à un n u̇d de transcription mettant en u̇vre une phase de cryptage/décryptage selon le protocole de protection de contenu ;- mise en u̇vre de la phase d'authentification selon le protocole de protection de contenu afin de s'authentifier auprès du dispositif source via le n u̇d source ; - transmission de paramètres permettant d'obtenir la première clé de cryptage au n u̇d de transcription ; Avantageusement, l'étape de mise en u̇vre d'une phase d'authentification afin d'authentifier le dispositif récepteur via le n u̇d récepteur et l'étape de mise en u̇vre de la phase d'authentification afin de s'authentifier auprès du dispositif source via le n u̇d source se font par l'intermédiaire du n u̇d de transcription; Préférentiellement, les n u̇ds d'authentification et de transcription sont distincts.
Ainsi, on peut par exemple mettre en u̇vre un n u̇d de transcription qui ne comprend que des moyens de cryptage / décryptage au sens DTCP et pas des moyens d'authentification DTCP et un n u̇d d'authentification qui ne comprend que des moyens d'authentification et pas des moyens de cryptage / décryptage.
L'invention concerne également un procédé d'échange de paquets de données dans un réseau de communication entre un dispositif source lié à un n u̇d source et un dispositif récepteur lié au n u̇d récepteur, les paquets de données provenant du dispositif source étant cryptés selon une première clé de cryptage, le procédé comportant les étapes suivantes mises en u̇vre par un n u̇d de transcription :
réception en provenance du n u̇d d'authentification de paramètres permettant d'obtenir la première clé de cryptage ; substitution desdits paramètres par introduction de paramètres propres au n u̇d de transcription ; envoi desdits paramètres substitués au dispositif source via le n u̇d source; Obtention de la première clé de cryptage à partir desdits paramètres substitués et de paramètres reçus du dispositif source via le n u̇d source; réception des paquets de données cryptés avec la première clé provenant du dispositif source via le n u̇d source ; réception en provenance du n u̇d d'authentification de paramètres permettant d'obtenir une seconde clé de cryptage ; substitution desdits paramètres par introduction de paramètres propres au n u̇d de transcription ; envoi desdits paramètres substitués au dispositif récepteur via le n u̇d récepteur ;Obtention de la seconde clé de cryptage à partir desdits paramètres substitués et de paramètres reçus du dispositif récepteur via le n u̇d récepteur ; décryptage des paquets de données avec la première clé et cryptage des paquets avec la seconde clé ; transmission des paquets de données cryptés avec la seconde clé de cryptage au dispositif récepteur via le n u̇d récepteur.
Avantageusement, l'envoi des paramètres substitués au dispositif source via le noeud source s'effectue à l'aide des paquets d'authentification échangés entre le dispositif source via le n u̇d source et le noeud d'authentification.
On utilise ainsi les ressources mises à disposition par le protocole de protection de contenus.
Préférentiellement, l'envoi des paramètres substitués au dispositif récepteur via le noeud récepteur s'effectue à l'aide les paquets d'authentification échangés entre le dispositif récepteur via le noeud récepteur et le noeud d'authentification.
Selon une caractéristique avantageuse conforme à l'invention, les paramètres en provenance du noeud d'authentification permettant d'obtenir la première clé de cryptage sont la première clé de cryptage.
Avantageusement, les paramètres en provenance du noeud d'authentification permettant d'obtenir la seconde clé de cryptage sont la seconde clé de cryptage.
Préférentiellement, les n u̇ds d'authentification et de transcription sont distincts.
L'invention concerne également un produit programme d'ordinateur, comprenant des instructions de code de programme pour l'exécution des étapes de l'un au moins des procédés d'échange de paquets tels que décrits précédemment, lorsque ledit programme est exécuté sur un ordinateur.
L'invention concerne également 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 u̇vre l'un au moins des procédés d'échange de paquets tels que décrits précédemment.
L'invention concerne également un n u̇d récepteur d'un réseau de communication permettant l'échange de paquets de données entre un dispositif source lié à un n u̇d source et un dispositif récepteur lié audit n u̇d récepteur, les paquets de données provenant du dispositif source étant cryptés selon une première clé de cryptage, le n u̇d récepteur comprenant :
des moyens de réception d'une requête d'authentification conforme à une phase d'authentification selon un protocole de protection de contenu, provenant du dispositif récepteur ; des moyens de transmission de la requête d'authentification à un n u̇d d'authentification du réseau de communication, mettant en u̇vre la phase d'authentification selon le protocole de protection de contenu, en vue de la mise en u̇vre d'une authentification du dispositif récepteur par le n u̇d d'authentification ; des moyens de réception de paramètres permettant d'obtenir une seconde clé de cryptage et des moyens de transmission de ces paramètres au dispositif récepteur ;des moyens de transmission au dispositif récepteur de paquets de données préalablement décryptés, avec la première clé de cryptage, et cryptés selon la seconde clé de cryptage, par un n u̇d de transcription mettant en u̇vre une phase de cryptage/décryptage selon le protocole de protection de contenu.
Préférentiellement, le n u̇d récepteur et le n u̇d de transcription sont confondus, et le n u̇d récepteur comprend également des moyens de substitution de paramètres initialement reçus du n u̇d d'authentification qui coopèrent avec les moyens de réception de paramètres permettant d'obtenir une seconde clé de cryptage.
Avantageusement, le n u̇d récepteur est distinct du n u̇d d'authentification.
Selon une caractéristique avantageuse conforme à l'invention, le n u̇d récepteur est confondu avec le n u̇d d'authentification.
L'invention concerne également un n u̇d source d'un réseau de communication permettant l'échange de paquets de données entre un dispositif source lié audit n u̇d source et un dispositif récepteur lié à un n u̇d récepteur, les paquets de données provenant du dispositif source étant cryptés selon une première clé de cryptage, le n u̇d source comportant :
des moyens de réception d'une requête d'authentification conforme à une phase d'authentification selon un protocole de protection de contenu, provenant d'un n u̇d d'authentification ; des moyens de transmission de la requête d'authentification au dispositif source, en vue de la mise en u̇vre d'une authentification du n u̇d d'authentification par le dispositif source ; des moyens de réception de paramètres permettant d'obtenir la première clé de cryptage du dispositif source et des moyens de transmission de ces paramètres au n u̇d d'authentification ; des moyens de réception des paquets de données cryptés avec la première clé de cryptage provenant du dispositif source ;des moyens de transmission au à un n u̇d de transcription mettant en u̇vre une phase de cryptage/décryptage selon le protocole de protection de contenu des paquets de données cryptés avec la première clé de cryptage afin qu'il puisse décrypter lesdites données au moyen de la première clé et ensuite les crypter au moyen d'une seconde clé de cryptage.
Selon un mode de mise en u̇vre avantageux conforme à l'invention, le n u̇d source est distinct du n u̇d de transcription.
Selon un autre mode de mise en u̇vre avantageux conforme à l'invention, le n u̇d source et le n u̇d de transcription sont confondus et le n u̇d source comprend en outre :
des moyens de transmission au dispositif récepteur via le n u̇d récepteur de paramètres permettant d'obtenir la seconde clé de cryptage après substitution de paramètres initialement reçus du n u̇d d'authentification ; des moyens de transmission au dispositif récepteur via le n u̇d récepteur des données cryptées avec la seconde clé.
Selon un mode de réalisation avantageux conforme à l'invention, le n u̇d source est distinct du n u̇d d'authentification.
Selon un autre mode de réalisation avantageux conforme à l'invention, le n u̇d source et le n u̇d d'authentification sont confondus.
L'invention concerne également un n u̇d d'authentification d'un réseau de communication permettant l'échange de paquets de données entre un dispositif source lié à un n u̇d source et un dispositif récepteur lié au n u̇d récepteur, les paquets de données provenant du dispositif source étant cryptés selon une première clé de cryptage, le n u̇d d'authentification comportant :
des premiers moyens d'authentification selon un protocole de protection de contenu afin d'authentifier le dispositif récepteur via le n u̇d récepteur ; des moyens de transmission de paramètres permettant d'obtenir une seconde clé de cryptage à un n u̇d de transcription mettant en u̇vre une phase de cryptage/décryptage selon le protocole de protection de contenu ; des seconds moyens d'authentification selon le protocole de protection de contenu afin de s'authentifier auprès du dispositif source via le n u̇d source ; des moyens de transmission de paramètres permettant d'obtenir la première clé de cryptage au n u̇d de transcription ;Avantageusement, le n u̇d d'authentification est distinct du noeud de transcription.
L'invention concerne également un n u̇d de transcription d'un réseau de communication permettant l'échange de paquets de données entre un dispositif source lié à un n u̇d source et un dispositif récepteur lié au n u̇d récepteur, les paquets de données provenant du dispositif source étant cryptés selon une première clé de cryptage, le n u̇d de transcription comportant : - des moyens de réception en provenance du n u̇d d'authentification de paramètres permettant d'obtenir la première clé de cryptage ; - des moyens de substitution desdits paramètres par introduction de paramètres propres au n u̇d de transcription ; - des moyens d'envoi desdits paramètres substitués au dispositif source via le n u̇d source ;- des moyens d'obtention de la première clé de cryptage à partir desdits paramètres substitués et de paramètres reçus du dispositif source via le n u̇d source; - des moyens de réception des paquets de données cryptés avec la première clé provenant du dispositif source via le n u̇d source ; - des moyens de réception en provenance du n u̇d d'authentification de paramètres permettant d'obtenir une seconde clé de cryptage ; - des moyens de substitution desdits paramètres par introduction de paramètres propres au n u̇d de transcription ; - des moyens d'envoi desdits paramètres substitués au dispositif récepteur via le n u̇d récepteur; des moyens d'obtention de la seconde clé de cryptage à partir desdits paramètres substitués et de paramètres reçus du dispositif récepteur via le n u̇d récepteur;des moyens de décryptage des paquets de données avec la première clé et cryptage des paquets avec la seconde clé ; des moyens de transmission des paquets de données cryptés avec la seconde clé de cryptage au dispositif récepteur via le n u̇d récepteur.
Avantageusement, le n u̇d de transcription est distinct du n u̇d d'authentification.
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 préférentiels, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels : - la figure 1A présente le schéma d'un réseau audio-vidéo domestique dans lequel peut être mis en u̇vre le procédé de l'invention ; - la figure 1B illustre l'unité centrale de commutation du réseau domestique de la figure 1 ; - la figure 2 présente un diagramme illustrant la mise en u̇vre du protocole DTCP en cascade selon l'art antérieur dans un réseau générique ; - -La figure 3 présente le schéma d'une implémentation d'un n u̇d 100 du réseau domestique 1000 selon un mode de mise en u̇vre particulier de l'invention ;- la figure 4 est un schéma illustrant l'échange du contenu cO entre le dispositif source et le dispositif récepteur dans le cadre d'un premier mode de réalisation du procédé d'échange selon l'invention ; - la figure 5 est un schéma illustrant l'échange du contenu cO entre le dispositif source et le dispositif récepteur dans le cadre d'un second mode de réalisation du procédé d'échange selon l'invention ; la figure 6 présente des algorithmes mis en u̇vre par les n u̇ds récepteur et mandataire dans le cadre d'un exemple de mise en u̇vre précité du procédé d'échange de données selon l'invention ; la figure 7 présente des algorithmes mis en u̇vre par le n u̇d source 003 dans le cadre de l'exemple de mise en u̇vre précité du procédé d'échange de données selon l'invention ;la figure 8 présente des algorithmes mis en u̇vre par le n u̇d récepteur dans le cadre d'une variante de l'exemple de mise en u̇vre précité du procédé d'échange de données selon l'invention ; la figure 9 présente des algorithmes mis en u̇vre par le n u̇d source dans le cadre de la mise en u̇vre du procédé d'échange de données de l'invention selon la variante précitée ; la figure 10 présente un algorithme mis en u̇vre par le n u̇d d'authentification 0051 dans le cadre de la mise en u̇vre du procédé d'échange de données de l'invention selon la variante précitée.
6. Description de plusieurs modes de réalisation de l'invention On se place, dans la suite, dans le cadre du réseau domestique 1000 de la figure lA. Il est clair cependant que l'invention peut être mise en u̇vre dans tout réseau de communication comprenant au moins un dispositif source connecté à un n u̇d source, échangeant au moins un contenu sous forme de paquets de données avec au moins un dispositif récepteur connecté à un n u̇d récepteur.
Par ailleurs, on considère dans la suite que le protocole de protection de contenus mis en u̇vre dans le réseau domestique 1000 est le protocole DTCP précité. Cependant, il est évident que l'invention s'applique également à tout protocole de protection de contenus comprenant une phase préalable d'authentification.
A titre d'exemple, on suppose dans la suite qu'un contenu cO, protégé contre la copie, par exemple un contenu audio-vidéo à accès restreint dans le réseau, est stocké sur l'unité de stockage 006 (autrement appelé dispositif source) reliée au n u̇d 003 (appelé ci-après n u̇d source). On suppose également qu'un utilisateur souhaite accéder à ce contenu cO par lecture de ce dernier sur le téléviseur numérique 009 (autrement appelé dispositif récepteur) relié au n u̇d 004 (appelé ci-après n u̇d récepteur).
On a ainsi, une transmission, dans le réseau domestique 1000 de la figure lA, d'un flux de données isochrones comprenant le contenu cO. Plus précisément, le flux isochrone est transmis depuis le dispositif source 006 vers le dispositif récepteur 009 via le réseau fédérateur 1001.
Il est clair que d'une façon plus générale un même flux peut être reçu simultanément par plusieurs dispositifs récepteurs connectés chacun à un n u̇d récepteur du réseau. Plusieurs dispositifs récepteurs peuvent éventuellement être connectés à un même n u̇d récepteur du réseau.
Bien entendu, dans la pratique, un même n u̇d peut jouer le rôle d'un n u̇d source si au moins un dispositif source lui est connecté et/ou le rôle d'un n u̇d récepteur si un dispositif récepteur lui est connecté. De la même manière, un même dispositif pourra être récepteur dans certaines transmissions de données et émetteur dans d'autres transmissions de données.
Selon une caractéristique préférentielle de l'invention, le n u̇d récepteur 004 comprend des moyens pour savoir si le contenu cO est à accès libre ou à accès restreint. Par exemple, il peut accéder à des informations d'une table référençant tous les contenus stockés sur le réseau et leur statut de restriction d'accès (les autres n u̇ds du réseau peuvent également avoir accès à ces informations).
Le procédé d'échange de données selon l'invention est mis en u̇vre 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) dans une ou plusieurs machines du réseau 1000, par exemple dans le n u̇d 100 décrit ci-après en relation avec la figure 3.
On présente, en relation avec la figure 3, le schéma d'une implémentation d'un n u̇d 100 entièrement compatible avec le protocole DTCP, du réseau domestique 1000 selon un mode de réalisation particulier de l'invention. On ne décrit, par soucis de simplicité, que ce n u̇d de générique 100 qui comprend des moyens de transcription ainsi que des moyens d'authentification. Ainsi, il peut représenter par exemple le n u̇d d'authentification 0051 ou le n u̇d de transcription 0052 du réseau domestique 1000.
Le n u̇d 100 est connecté à la fois au réseau fédérateur 1001 (dont on a représenté sur cette figure 3 l'unité centrale de commutation 015) via un lien numérique, à un bus IEEE-1394 124 et à des dispositifs terminaux analogiques référencés Ra1, Sal et Sa2 via des liens analogiques. Le n u̇d 100 comprend une interface réseau fédérateur 101 avec le réseau fédérateur 1001 utilisé par le contrôleur de réseau domestique 102 afin de transmettre et/ou recevoir des paquets sur et/ou provenant du réseau fédérateur 1001. Le contrôleur de réseau fédérateur 102 gère aussi le format de ces paquets.
Dans le n u̇d 100, une mémoire tampon de transmission 103 mise en u̇vre pour les transmissions de données sur le réseau et une mémoire tampon de réception 104 pour la réception de données provenant du réseau.
Un module d'interface microprocesseur 105 est chargé d'assurer l'interface avec le microprocesseur (référencé CPU pour Central Processing Unit en anglais) 121 afin de décoder le registre CPU et mettre en u̇vre les transferts DMA (pour Direct Memory Access ou accès mémoire directs en français) gérés par le microprocesseur 121 depuis ou vers le bloc mémoire SDRAM (pour Synchronous Dual Random Access Memory ou mémoire vive dynamique synchrone en français) 120.
Un module d'interface bus série 106 réalise les interfaces couche physique et couche de lien du bus IEEE-1394 en respectant la norme IEEE-1394.
Un module d'interface audio-vidéo 107 réalise le formatage (assemblage) et le déformatage (désassemblage) des paquets des flux IEEE-1394 envoyés sur le bus IEEE selon des recommandations du document de référence suivant : IEC Std 61883, Consumer audio/video equipment - Digital interface .
Le n u̇d 100 comprend également des décodeurs/encodeurs MPEG2 108, 109, 110 connectés respectivement à des ports d'entrées/sortie audio-video 111, 112 et 113 qui sont eux-mêmes reliés respectivement aux terminaux analogiques Ra1, Sa1 et Sa2.
Un module de contrôle de transition 114 assure :
la mise en u̇vre de toutes les opérations critiques au niveau temporel associées au portail de transition IEEE-1394 (tel que décrit dans le document de référence suivant : IEEE P1394.1 Draft 0.15 Standard for High Performance Sériai Bus Bridges ) dont notamment :
la surveillance des paquets arrivant ; - la génération d'accusés de réception ; - la gestion du routage isochrone et asynchrone ; la synchronisation de l'horloge IEEE-1394 ; la gestion des requêtes de transfert isochrone entre :
l'interface bus série 106 et l'interface réseau fédérateur 101 ; l'interface bus série 106 et l'interface microprocesseur 105 ; la mise en u̇vre des opérations suivantes sur les en-têtes de flux quand c'est nécessaire :
suppression ; requête d'insertion ; horodatage ; la réception de tous les signaux d'interface liés à l'interface signaux d'indicateur de présence et d'interruption ( Status and Interrupt Signais en anglais) de l'interface bus série 106 ; la réception de tous les signaux d'interface liés à l'interface signaux interface d'accès au registre physique ( PHY Register Access Interface Signais en anglais) de l'interface bus série 106.
Le n u̇d 100 comprend un module de décryptage et un module de cryptage qui mettent en u̇vre respectivement l'algorithme de décryptage l'algorithme de cryptage de type DTCP.
Un module FIFO ( First in First out en anglais ou premier entré premier sorti en français) de transmission isochrone 117 qui implémente une FIFO isochrone de 2Kx32 bits.
Un module FIFO de réception isochrone 118 qui implémente une FIFO isochrone de 2Kx32 bits.
Le n u̇d 100 comprend également un module de détection de protection contre la copie 119 qui détecte les droits de protection contre la copie au moyen de l'analyse des champs EMI (voir la définition des bits EMI dans Digital Transmission Content Protection Specification, Volume 1 et 2, Draft 1.29 ) contenus dans l'en-tête des paquets du flux isochrone.
Il comprend également un bloc de mémoire Flash 122 connecté au module d'interface microprocesseur 105.
Dans le cadre des figures 4 et 5 ci-après décrites et résumant le principe de l'invention, on se place dans une configuration préférentielle du réseau domestique 1000 mettant en u̇vre le procédé selon l'invention dans laquelle le n u̇d 0051 joue le rôle de n u̇d d'authentification et le n u̇d 0052 joue le rôle de n u̇d de transcription.
Ceci peut être défini lors d'une phase préalable de paramétrage du réseau domestique 1000. Bien entendu, dans d'autres configurations du réseau domestique 1000 dans le cadre de l'invention, chacun des n u̇ds 003, 004, 0051, 0052 peut jouer le rôle de n u̇d d'authentification et/ou de n u̇d de transcription.
Avantageusement, tout n u̇d du réseau domestique 1000 peut ne pas comprendre les modules de cryptage 116 et de décryptage 115 précités (liés au cryptage et au décryptage DTCP) où le module 119 ... (liés à l'authentification DTCP) s'il ne participe pas respectivement aux cryptage/décryptage et aux authentifications.
La figure 4 est un schéma illustrant l'échange du contenu cO entre le dispositif source 006 et le dispositif récepteur 009 du réseau domestique 1000 dans le cadre d'un premier mode de réalisation du procédé d'échange selon l'invention.
Afin que le dispositif récepteur 009 puisse avoir accès au contenu cO stocké sur le dispositif source 006, plusieurs étapes sont mises en u̇vre, nous les décrivons ci-après.
Une première authentification 401 est mise en u̇vre entre le n u̇d d'authentification 0051 et le dispositif source 006 au moyen d'au moins deux requêtes d'authentification, émises par le n u̇d d'authentification 0051 vers le dispositif source 006 et par le dispositif source 006 vers le n u̇d d'authentification 0051. Lors de la première authentification 401, les requêtes transitent par le n u̇d source 006 et par le n u̇d de transcription 0052.
Lors de cette première authentification 401 :
le n u̇d source 003 ne fait que transférer les requêtes d'authentification, le n u̇d de transcription 0052 substitue des premiers paramètres d'authentification qu'il a préalablement généré à des paramètres d'authentification des requêtes provenant du n u̇d d'authentification 0051 et qui sont propres à ce n u̇d d'authentification 0051.
Ainsi, le n u̇d de transcription 0052 peut déterminer à partir des requêtes d'authentification de la première authentification 401 une première clé de cryptage K1.
Une seconde authentification 402 est également mise en u̇vre entre le n u̇d d'authentification 0051 et le dispositif récepteur 009 au moyen d'au moins deux requêtes d'authentification, émises par le dispositif récepteur 009 vers le n u̇d d'authentification 0051 et par le n u̇d d'authentification 0051 vers le dispositif récepteur 009. Lors de la seconde authentification 402, les requêtes transitent par le n u̇d récepteur 004 et par le n u̇d de transcription 0052.
Lors de cette seconde authentification 402 :
le n u̇d récepteur 004 ne fait que transférer les requêtes d'authentification, le n u̇d de transcription 0052 substitue des seconds paramètres d'authentification qu'il a préalablement généré à des paramètres d'authentification de la requête provenant du n u̇d d'authentification 0051 et qui sont propres à ce n u̇d d'authentification 0051.
Ainsi, le n u̇d de transcription 0052 peut déterminer à partir des requêtes d'authentification de la seconde authentification 402 une seconde clé de cryptage K2.
Le dispositif source 006, après avoir crypté le contenu cO au moyen de la première clé K1, le transmet, via le n u̇d source 003, qui ne fait que transférer ce contenu, au n u̇d de transcription 0052. Le n u̇d de transcription 0052 décrypte au moyen de la première clé de cryptage Kl le contenu cO et le crypte au moyen de la seconde clé de cryptage K2 avant de transmettre, via le n u̇d récepteur 004 (qui ne fait que transférer ce contenu) au dispositif récepteur 009.
Finalement, le n u̇d récepteur 009 décrypte le contenu cO au moyen de la seconde clé de cryptage qu'il obtient lors de la seconde authentification précitée.
La figure 5 est un schéma illustrant l'échange du contenu cO entre le dispositif source 006 et le dispositif récepteur 009 du réseau domestique 1000 dans le cadre d'un second mode de réalisation du procédé d'échange selon l'invention.
Afin que le dispositif récepteur 009 puisse avoir accès au contenu cO stocké sur le dispositif source 006, plusieurs étapes sont mises en u̇vre, nous les décrivons ci-après.
Une première authentification 501 est mise en u̇vre entre le n u̇d d'authentification 0051 et le dispositif source 006 au moyen d'au moins deux requêtes d'authentification, émises par le n u̇d d'authentification 0051 vers le dispositif source 006 et par le dispositif source 006 vers le n u̇d d'authentification 0051. Lors de cette première authentification 501, les requêtes transitent par le n u̇d source 003 qui ne fait que les transférer.
Une seconde authentification 502 est également mise en u̇vre entre le n u̇d d'authentification 0051 et le dispositif récepteur 009 au moyen d'au moins deux requêtes d'authentification, émises par le dispositif récepteur 009 vers le n u̇d d'authentification 0051 et par le n u̇d d'authentification 0051 vers le dispositif récepteur 009. Lors de cette seconde authentification 502, les requêtes transitent par le n u̇d récepteur 004 qui ne fait que les transférer.
Le n u̇d d'authentification 0051 transmet 503, 504 une première et une seconde clé de cryptage K1 et K2 obtenues respectivement lors des première et seconde authentifications par le n u̇d d'authentification 0051 au n u̇d de transcription 0052.
Le dispositif source 006, après avoir crypté le contenu cO au moyen de la première clé K1, le transmet, via le n u̇d source 003, qui ne fait que transférer ce contenu, au n u̇d de transcription 0052. Le n u̇d de transcription 0052 décrypte au moyen de la première clé de cryptage K1 le contenu cO et le crypte au moyen de la seconde clé de cryptage K2 avant de transmettre, via le n u̇d récepteur 004 (qui ne fait que transférer ce contenu) au dispositif récepteur 009.
Finalement, le n u̇d récepteur 009 décrypte le contenu cO au moyen de la seconde clé de cryptage qu'il obtient lors de la seconde authentification précitée.
On se place dans la suite dans un exemple de mise en u̇vre du procédé d'échange de données selon l'invention selon lequel les n u̇ds d'authentification 0051 et de transcription 0052 sont confondus et ci-après désignés par n u̇d mandataire. Le n u̇d mandataire est un n u̇d entièrement compatible avec le protocole DTCP. Cet exemple de réalisation peut être mis en u̇vre soit dans le cadre du premier mode de réalisation précité, soit dans le cadre du second mode de réalisation précité.
On présente, en relation avec la figure 6, des algorithmes mis en u̇vre par les n u̇ds récepteur 004 et mandataire dans le cadre de l'exemple de mise en u̇vre précité du procédé d'échange de données selon l'invention.
On se place dans un premier temps au niveau du n u̇d récepteur 004, à un niveau matériel.
Dans une première étape 200, le statut de protection contre la copie d'un paquet de données du contenu cO est identifié. Dans une seconde étape 201, les champs de protection contre la copie spécifique au protocole DTCP de l'entête isochrone des paquets de données sont analysés. Dans le cas d'une protection active contre la copie, dans une troisième étape 202, le statut de protection contre la copie est déclenché en même temps que le numéro de canal isochrone associé afin que le logiciel selon l'invention puisse mettre en u̇vre les étapes suivantes.
On se place ensuite à un niveau logiciel.
Dans une première étape 203, le statut de protection contre la copie du contenu cO est déclenché (tel qu'expliqué précédemment). Ensuite, dans une seconde étape 204, le n u̇d mandataire à l'écoute est identifié au moyen du numéro de canal isochrone du flux protégé correspondant au contenu cO. Dans une troisième étape 205, à compter de l'identification précitée du n u̇d mandataire, le n u̇d récepteur 004 transfère toutes les étapes du protocole DTCP échangées entre le n u̇d mandataire et le dispositif récepteur 009.
On se place maintenant au niveau du n u̇d mandataire, à un niveau logiciel.
Dans une première étape 206, une requête d'authentification provenant du n u̇d récepteur 004 (transférée par le n u̇d récepteur 004) est reçue par le n u̇d mandataire. Ensuite, dans une seconde étape 207, le noeud mandataire met en u̇vre la seconde authentification précédemment décrite en relation avec les figures 4 et 5 (respectivement pour les premier et second modes de réalisation précités) avec le dispositif récepteur 009 via le n u̇d récepteur 004.
Dans une troisième étape 208, on vérifie si la seconde authentification est réussie. Si la seconde authentification échoue, l'algorithme retourne à la première étape 206.
Si la seconde authentification est réussie, dans une quatrième étape 209, un identifiant DTCP du n u̇d source 003 est obtenu par le n u̇d mandataire à partir de la requête d'authentification préalablement reçue. Ensuite, dans une cinquième étape 210, le n u̇d mandataire met en u̇vre la première authentification précédemment décrite en relation avec les figures 4 et 5 (respectivement pour les premier et second mode de réalisation précités) avec le dispositif source 006 via le n u̇d source 003.
Dans une sixième étape 211, on vérifie si la première authentification est réussie. Si la première authentification échoue, l'algorithme retourne à la première étape 206.
Si la première authentification est réussie, dans une septième étape 212, le n u̇d mandataire décrypte puis crypte les données du contenu cO reçues préalablement envoyées par le dispositif source 006 et transférées par le n u̇d source 003, respectivement avec les première et seconde clés. Dans une huitième étape 213, le n u̇d mandataire route les données ainsi décryptées puis cryptées vers le dispositif récepteur 009 via le n u̇d récepteur 004.
On présente, en relation avec la figure 7, des algorithmes mis en u̇vre par le n u̇d source 003 dans le cadre de l'exemple de mise en u̇vre précité du procédé d'échange de données selon l'invention.
On se place dans un premier temps à un niveau composant.
Dans une première étape 300, le statut de protection contre la copie d'un paquet de données du contenu cO est identifié. Dans une seconde étape 301, les champs de protection contre la copie spécifique au protocole DTCP de l'entête isochrone des paquets de données sont analysés. Dans le cas d'une protection active contre la copie, dans une troisième étape 302, le statut de protection contre la copie est déclenché en même temps que le numéro de canal isochrone associé afin que le logiciel selon l'invention puisse mettre en u̇vre les étapes suivantes.
On se place ensuite à un niveau logiciel.
Dans une première étape 303, le statut de protection contre la copie du contenu cO est déclenché (tel qu'expliqué précédemment). Ensuite, dans une seconde étape 204, le n u̇d mandataire à l'écoute est identifié, par exemple, au moyen du numéro de canal isochrone du flux protégé correspondant au contenu cO.
Selon une variante de cet exemple de mise en u̇vre du procédé d'échange de données selon laquelle les n u̇ds d'authentification 0051 et de transcription 0052 ne sont pas confondus, le n u̇d mandataire jouant le rôle du n u̇d d'authentification 0051, le n u̇d source 003 identifie également le n u̇d de transcription 0052.
Dans une troisième étape 305, à compter de l'identification précitée du n u̇d mandataire, le n u̇d source 003 transfère toutes les étapes du protocole DTCP échangées entre le dispositif source 006 et le n u̇d mandataire.
Dans la variante précitée, lors de la troisième étape 305, le n u̇d source 003 transfère toutes les étapes du protocole DTCP échangées entre le dispositif source 006, le n u̇d d'authentification 0051 et le n u̇d de transcription 0052.
Dans une quatrième étape 306, on vérifie si l'authentification est réussie. Si l'authentification échoue, l'algorithme retourne à la première étape 303.
Si l'authentification réussie, dans une cinquième étape 307, le n u̇d source 003 transfère le flux crypté correspondant au contenu cO provenant du dispositif source 006 au n u̇d mandataire.
Dans la variante précitée, lors de la cinquième étape 307, le n u̇d source 003 transfère le flux crypté correspondant au contenu cO provenant du dispositif source 006 au n u̇d de transcription 0052.
Les mêmes algorithmes que ceux mis en u̇vre par le n u̇d source 003 précédemment décrits en relation avec la figure 7, sont mis en u̇vre par n u̇d récepteur 004 dans le cadre de la mise en u̇vre du procédé d'échange de données selon l'invention. Nous ne les décrivons pas par soucis de simplicité.
On présente, en relation avec la figure 8, des algorithmes mis en u̇vre par le n u̇d récepteur 004 dans le cadre de la mise en u̇vre du procédé d'échange de données de l'invention selon la variante précitée (n u̇d d'authentification et n u̇d de transcription non confondus). Cependant, dans le cadre de cette figure 8, le n u̇d de transcription 0052 est confondu avec le n u̇d récepteur 004, on continue à l'appeler n u̇d récepteur 004 dans la suite.
On se place dans un premier temps à un niveau composant.
Dans une première étape 800, le statut de protection contre la copie d'un paquet de données du contenu cO est identifié. Dans une seconde étape 801, les champs de protection contre la copie spécifique au protocole DTCP de l'entête isochrone des paquets de données sont analysés. Dans le cas d'une protection active contre la copie, dans une troisième étape 802, le statut de protection contre la copie est déclenché en même temps que le numéro de canal isochrone associé afin que le logiciel selon l'invention puisse mettre en u̇vre les étapes suivantes.
On se place ensuite à un niveau logiciel.
Dans une première étape 803, le statut de protection contre la copie du contenu cO est déclenché (tel qu'expliqué précédemment). Ensuite, dans une seconde étape 804, le n u̇d d'authentification 0051 à l'écoute est identifié, par exemple, au moyen du numéro de canal isochrone du flux protégé correspondant au contenu cO ou à partir d'informations de routage spécifiques dans l'entête de routage des paquets du contenu cO.
Dans une troisième étape 805, à compter de l'identification précitée du n u̇d d'authentification 0051, le n u̇d récepteur 004 transfère toutes les étapes du protocole DTCP échangées entre le n u̇d d'authentification 0051 et le dispositif récepteur 009.
Dans une quatrième étape 806, le noeud récepteur 004 substitue alors les paramètres de calcul de clé de cryptage émis par le n u̇d d'authentification 0051 par des paramètres de calcul de clé qui lui sont propres à partir des paquets de données du protocole d'échange de clé DTCP associé.
Dans une cinquième étape 807, on vérifie si l'authentification est réussie. Si l'authentification échoue, l'algorithme retourne à la première étape 803.
Si l'authentification réussie, dans une sixième étape 808, la première clé de cryptage est calculée et le n u̇d récepteur 004 décrypte les paquets de données du contenu cO provenant du n u̇d source au moyen de la première clé de cryptage. Le n u̇d récepteur aura reçu au préalable des paramètres de calcul de la première clé de cryptage lors de l'authentification du dispositif source.
Dans une septième étape 809, le n u̇d récepteur 004 commence à crypter les paquets de données sortant au moyen de la seconde clé de cryptage générée au moyen des paramètres de calcul de clé qui lui sont propres.
On peut noter que le fait que le n u̇d récepteur 004 utilise ses propres paramètres de calcul de clé au lieu des paramètres du n u̇d d'authentification 0051 est important dans le cadre de ce mode de réalisation (décrit en relation avec la figure 4) du fait que le n u̇d récepteur ne peut pas obtenir les paramètres de calcul de clé du n u̇d d'authentification 0051 à partir des paquets d'authentification échangés.
On présente, en relation avec la figure 9, des algorithmes mis en u̇vre par le n u̇d source 003 dans le cadre de la mise en u̇vre du procédé d'échange de données de l'invention selon la variante précitée (n u̇d d'authentification et n u̇d de transcription non confondus). Cependant, dans le cadre de cette figure 9, le n u̇d de transcription 0052 est confondu avec le n u̇d source 003, on continue à l'appeler n u̇d source 003 dans la suite.
Le n u̇d source 003 met en u̇vre les étapes 800 à 804 précédemment décrites en relation avec la figure 8.
Ensuite, dans une étape 905, à compter de l'identification du n u̇d d'authentification 0051 lors de l'étape 804, le n u̇d source 003 transfère toutes les étapes du protocole DTCP échangées entre le dispositif source 006 et le n u̇d d'authentification 0051.
Dans une étape 906, le noeud source 003 substitue alors les paramètres de calcul de clé de cryptage émis par le n u̇d d'authentification 0051 par des paramètres de calcul de clé qui lui sont propres à partir des paquets de données du protocole d'échange de clé DTCP associé.
Dans une étape 907, on vérifie si l'authentification est réussie. Si l'authentification échoue, l'algorithme retourne à la première étape 803.
Si l'authentification réussie, dans une étape 908, la première clé de cryptage est calculée, le n u̇d source 003 décrypte les paquets de données entrant du contenu cO au moyen de la première clé de cryptage et crypte (étape 909) les paquets sortant correspondants au moyen de la seconde clé de cryptage. Les première et seconde clés de cryptage étant générée au moyen des paramètres de calcul de clé qui sont propres au n u̇d source 003.
On peut noter que le fait que le n u̇d source 003 utilise ses propres paramètres de calcul de clé au lieu des paramètres du n u̇d d'authentification 0051 est important dans ce mode de réalisation (décrit en référence à la figure 4) du fait que le n u̇d source ne peut pas obtenir les paramètres de calcul de clé du n u̇d d'authentification 0051 à partir des paquets d'authentification échangés.
On présente, en relation avec la figure 10, un algorithme mis en u̇vre par le n u̇d d'authentification 0051 dans le cadre de la mise en u̇vre du procédé d'échange de données de l'invention selon la variante précitée (n u̇d d'authentification et n u̇d de transcription non confondus).
Dans une première étape 10000, une requête d'authentification provenant du n u̇d récepteur 004 (transférée par le n u̇d récepteur 004) est reçue par le n u̇d d'authentification 0051. Ensuite, dans une seconde étape 10010, le noeud d'authentification 0051 met en u̇vre la seconde authentification précédemment décrite en relation avec les figures 4 et 5 (respectivement pour les premier et second modes de réalisation précités) avec le dispositif récepteur 009 via le n u̇d récepteur 004.
Dans une troisième étape 1002, on vérifie si la seconde authentification est réussie. Si la seconde authentification échoue, l'algorithme retourne à la première étape 10000.
Si la seconde authentification est réussie, dans une quatrième étape 1003, un identifiant DTCP du n u̇d source 003 est obtenu par le n u̇d d'authentification 0051 à partir de la requête d'authentification préalablement reçue.
Ensuite, dans une cinquième étape 1004, le n u̇d d'authentification 0051 met en u̇vre la première authentification précédemment décrite en relation avec les figures 4 et 5 (respectivement pour les premier et second mode de réalisation précités) avec le dispositif source 006 via le n u̇d source 003.
Dans une sixième étape 1005, on vérifie si la première authentification est réussie. Si la première authentification échoue, l'algorithme retourne à la première étape 10000.
Si la première authentification est réussie, dans une septième étape 1006, le n u̇d d'authentification 0051 transfère les paramètres de calcul de clé comprenant entre autres, la clé d'échange AKE (pour Authentication Key Exchange comme décrit dans le standard DTCP) propres au dispositif source 006 au n u̇d de transcription 0052. Le noeud source pourra alors transférer (étape 1007) au n u̇d de transcription 0052, le flux crypté correspondant au contenu cO émis par le dispositif source 006.
Bien que l'invention ait été décrite ci-dessus en relation avec un nombre limité de modes de réalisation, l'homme du métier, à la lecture de la présente description, comprendra que d'autres modes de réalisation peuvent être imaginés sans sortir du cadre de la présente invention.
REVENDICATIONS
1. Procédé d'échange de paquets de données dans un réseau de communication entre un dispositif source (006) lié à un n u̇d source (003) et un dispositif récepteur (009) lié à un n u̇d récepteur (004), les paquets de données provenant du dispositif source (006) étant cryptés selon une première clé de cryptage, caractérisé en ce qu'il comporte les étapes suivantes mises en u̇vre par le n u̇d récepteur (004) :
réception d'une requête d'authentification conforme à une phase d'authentification selon un protocole de protection de contenu, provenant du dispositif récepteur (009) ; transmission de la requête d'authentification à un n u̇d d'authentification (0051) du réseau de communication, mettant en u̇vre la phase d'authentification selon le protocole de protection de contenu, en vue de la mise en u̇vre d'une authentification du dispositif récepteur (009) par le n u̇d d'authentification (0051) ; réception de paramètres permettant d'obtenir une seconde clé de cryptage et transmission de ces paramètres au dispositif récepteur (009) ;transmission au dispositif récepteur (009) de paquets de données préalablement décryptés, avec la première clé de cryptage, et cryptés selon la seconde clé de cryptage, par un n u̇d de transcription (0052) mettant en u̇vre une phase de cryptage/décryptage selon le protocole de protection de contenu.

Claims (27)

  1. 2. Procédé selon la revendication 1, caractérisé en ce que la mise en u̇vre de l'authentification du dispositif récepteur s'effectue par le transfert d'au moins deux requêtes d'authentification entre le dispositif récepteur et le n u̇d d'authentification.
  2. 3. Procédé selon la revendication 1 ou 2, caractérisé en ce que la transmission de la ou des requêtes d'authentification à un n u̇d d'authentification se fait par l'intermédiaire du n u̇d de transcription.
  3. 4. Procédé selon l'une quelconque des revendications 1 à 3 caractérisé en ce que le n u̇d récepteur (004) est distinct du n u̇d de transcription (0052) et en ce que les paramètres permettant d'obtenir une seconde clé de cryptage sont des paramètres introduits par le n u̇d de transcription et reçus de ce dit n u̇d.
    5. Procédé selon l'une quelconque des revendications 1 à 4 caractérisé en ce que le n u̇d récepteur (004) et le n u̇d de transcription (0052) sont confondus, et en ce que l'étape de réception de paramètres permettant d'obtenir une seconde clé de cryptage comprend une étape de substitution de paramètres initialement reçus du n u̇d d'authentification (0051).
  4. 6. Procédé selon la revendication 5, caractérisé en ce que le procédé comprend en outre une étape de réception en provenance du n u̇d d'authentification (0051) de paramètres permettant d'obtenir la première clé de cryptage.
  5. 7. Procédé selon la revendication 1 ou 2, caractérisé en ce que l'étape de réception de paramètres permettant d'obtenir une seconde clé de cryptage consiste en une étape de réception de la seconde clé de cryptage envoyée par le n u̇d d'authentification (0052).
    8. Procédé selon la revendication 7, caractérisé en ce que le n u̇d récepteur et le n u̇d de transcription sont confondus et en ce que le procédé comprend en outre une étape de réception en provenance du n u̇d d'authentification (0051) de la première clé de cryptage.
  6. 9. Procédé selon l'une quelconque des revendications 1 à 8 caractérisé en ce que le n u̇d récepteur (004) est distinct du n u̇d d'authentification (0051).
  7. 10. Procédé selon l'une quelconque des revendications 1 à 8 caractérisé en ce que le n u̇d récepteur (004) et le n u̇d d'authentification (0051) sont confondus.
  8. 11. Procédé selon l'une quelconque des revendications 1 à 10 caractérisé en ce que le protocole de protection de contenu est le protocole DTCP.
    12. Procédé d'échange de paquets de données dans un réseau de communication entre un dispositif source (006) lié à un n u̇d source (003) et un dispositif récepteur (009) lié à un n u̇d récepteur (004), les paquets de données provenant du dispositif source (006) étant cryptés selon une première clé de cryptage, caractérisé en ce qu'il comporte les étapes suivantes mises en u̇vre par le n u̇d source (003) :
    - réception d'une requête d'authentification conforme à une phase d'authentification selon un protocole de protection de contenu, provenant d'un n u̇d d'authentification (0051) ;
    - transmission de la requête d'authentification au dispositif source (006), en vue de la mise en u̇vre d'une authentification du n u̇d d'authentification
    (0051) par le dispositif source (006) ;
    - réception de paramètres permettant d'obtenir la première clé de cryptage du dispositif source et transmission de ces paramètres au n u̇d d'authentification (0051) ;
    - réception des paquets de données cryptés avec la première clé de cryptage provenant du dispositif source (006) ;
    - transmission à un n u̇d de transcription (0052) mettant en u̇vre une phase de cryptage/décryptage selon le protocole de protection de contenu des paquets de données cryptés avec la première clé de cryptage afin qu'il puisse décrypter lesdites données au moyen de la première clé et ensuite les crypter au moyen d'une seconde clé de cryptage.
    13. Procédé selon la revendication 12, caractérisé en ce que la mise en u̇vre de l'authentification du n u̇d d'authentification s'effectue par le transfert d'au moins deux requêtes d'authentification entre le dispositif source et le n u̇d d'authentification.
  9. 14. Procédé selon la revendication 12 ou 13, caractérisé en ce que l'étape de transmission au n u̇d d'authentification (0051) de paramètres permettant d'obtenir la première clé dé cryptage se fait par l'intermédiaire du n u̇d de transcription.
  10. 15. Procédé selon la revendication 12 ou 13, caractérisé en ce que l'étape de transmission au n u̇d d'authentification (0051) de paramètres permettant d'obtenir la première clé dé cryptage consiste en une étape de transmission au n u̇d d'authentification (0051) de la première clé de cryptage.
    16. Procédé selon l'une des revendications 12 à 14 caractérisé en ce que le n u̇d source (003) est distinct du n u̇d de transcription (0052).
  11. 17. Procédé selon l'une des revendications 12 à 14 caractérisé en ce que le n u̇d source (003) et le n u̇d de transcription (0052) sont confondus et en ce que le procédé comprend en outre : une étape de transmission au dispositif récepteur (009) via le n u̇d récepteur de paramètres permettant d'obtenir la seconde clé de cryptage après substitution de paramètres initialement reçus du n u̇d d'authentification (0051) ; une étape de transmission au dispositif récepteur (009) via le n u̇d récepteur des données cryptées avec la seconde clé.
  12. 18. Procédé selon l'une quelconque des revendications 12 à 17 caractérisé en ce que le n u̇d source (003) est distinct du n u̇d d'authentification (0051).
    19. Procédé selon l'une quelconque des revendications 12 à 17 caractérisé en ce que le n u̇d source (003) et le n u̇d d'authentification (0051) sont confondus.
  13. 20. Procédé selon l'une quelconque des revendications 12 à 19 caractérisé en ce que le protocole de protection de contenu est le protocole DTCP.
    21. Procédé d'échange de paquets de données dans un réseau de communication entre un dispositif source (006) lié à un n u̇d source (003) et un dispositif récepteur (009) lié au n u̇d récepteur (004), les paquets de données provenant du dispositif source (006) étant cryptés selon une première clé de cryptage, caractérisé en ce qu'il comporte les étapes suivantes mises en u̇vre par un n u̇d d'authentification (0051) : mise en u̇vre d'une phase d'authentification selon un protocole de protection de contenu afin d'authentifier le dispositif récepteur (009) via le n u̇d récepteur (004) ; transmission de paramètres permettant d'obtenir une seconde clé de cryptage à un n u̇d de transcription (0052) mettant en u̇vre une phase de cryptage/décryptage selon le protocole de protection de contenu ; mise en u̇vre de la phase d'authentification selon le protocole de protection de contenu afin de s'authentifier auprès du dispositif source
    (006) via le n u̇d source (003) ; transmission de paramètres permettant d'obtenir la première clé de cryptage au n u̇d de transcription (0052) ;
  14. 22. Procédé selon la revendication 21, caractérisé en ce que l'étape de mise en u̇vre d'une phase d'authentification afin d'authentifier le dispositif récepteur
    (009) via le n u̇d récepteur (004) et l'étape de mise en u̇vre de la phase d'authentification afin de s'authentifier auprès du dispositif source (006) via le n u̇d source (003) se font par l'intermédiaire du n u̇d de transcription;
  15. 23. Procédé selon l'une quelconque des revendications 21 et 22 caractérisé en ce que les n u̇ds d'authentification (0051) et de transcription (0052) sont distincts.
    24. Procédé d'échange de paquets de données dans un réseau de communication entre un dispositif source (006) lié à un n u̇d source (003) et un dispositif récepteur (009) lié au n u̇d récepteur (004), les paquets de données provenant du dispositif source (006) étant cryptés selon une première clé de cryptage, caractérisé en ce qu'il comporte les étapes suivantes mises en u̇vre par un n u̇d de transcription (0052) :
    - réception en provenance du n u̇d d'authentification (0051) de paramètres permettant d'obtenir la première clé de cryptage ;
    - substitution desdits paramètres par introduction de paramètres propres au n u̇d de transcription ;
    - envoi desdits paramètres substitués au dispositif source (006) via le n u̇d source (003);
    - Obtention de la première clé de cryptage à partir desdits paramètres substitués et de paramètres reçus du dispositif source via le n u̇d source;
    - réception des paquets de données cryptés avec la première clé provenant du dispositif source (006) via le n u̇d source (003) ;
    - réception en provenance du n u̇d d'authentification (0051) de paramètres permettant d'obtenir une seconde clé de cryptage ; substitution desdits paramètres par introduction de paramètres propres au n u̇d de transcription ; envoi desdits paramètres substitués au dispositif récepteur (009) via le n u̇d récepteur (004); Obtention de la seconde clé de cryptage à partir desdits paramètres substitués et de paramètres reçus du dispositif récepteur (009) via le n u̇d récepteur (004); décryptage des paquets de données avec la première clé et cryptage des paquets avec la seconde clé ; transmission des paquets de données cryptés avec la seconde clé de cryptage au dispositif récepteur (009) via le n u̇d récepteur (004).
  16. 25. Procédé selon la revendication 24 caractérisé en ce que l'envoi des paramètres substitués au dispositif source (006) via le noeud source (003) s'effectue à l'aide des paquets d'authentification échangés entre le dispositif source (003) via le n u̇d source (006) et le noeud d'authentification (0051).
    26. Procédé selon la revendication 24 ou 25 caractérisé en ce que l'envoi des paramètres substitués au dispositif récepteur (009) via le noeud récepteur (004) s'effectue à l'aide les paquets d'authentification échangés entre le dispositif récepteur (004) via le noeud récepteur (004) et le noeud d'authentification (0051).
  17. 27. Procédé selon la revendication 24 caractérisé en ce que les paramètres en provenance du noeud d'authentification (0051) permettant d'obtenir la première clé de cryptage sont la première clé de cryptage.
  18. 28. Procédé selon la revendication 27 caractérisé en ce que les paramètres en provenance du noeud d'authentification (0051) permettant d'obtenir la seconde clé de cryptage sont la seconde clé de cryptage.
    29. Procédé selon l'une quelconque des revendications 24 à 28 caractérisé en ce que les n u̇ds d'authentification (0051) et de transcription (0052) sont distincts.
  19. 30. Produit programme d'ordinateur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution des étapes du procédé d'échange de paquets selon l'une quelconque des revendications 1 à 11 et/ou 12 à
    20 et/ou 21 à 23 et/ou 24 à 29, lorsque ledit programme est exécuté sur un ordinateur.
  20. 31. 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 u̇vre le procédé d'échange de paquets selon l'une quelconque des revendications 1 à 11 et/ou 12 à 20 et/ou 21 à 23 et/ou 24 à 29.
    32. N u̇d récepteur d'un réseau de communication permettant l'échange de paquets de données entre un dispositif source (006) lié à un n u̇d source (003) et un dispositif récepteur (009) lié audit n u̇d récepteur (004), les paquets de données provenant du dispositif source (006) étant cryptés selon une première clé de cryptage, caractérisé en ce qu'il comprend : des moyens de réception d'une requête d'authentification conforme à une phase d'authentification selon un protocole de protection de contenu, provenant du dispositif récepteur (009) ; des moyens de transmission de la requête d'authentification à un n u̇d d'authentification (0051) du réseau de communication, mettant en u̇vre la phase d'authentification selon le protocole de protection de contenu, en vue de la mise en u̇vre d'une authentification du dispositif récepteur
    (009) par le n u̇d d'authentification (0051) ; des moyens de réception de paramètres permettant d'obtenir une seconde clé de cryptage et des moyens de transmission de ces paramètres au dispositif récepteur (009) ; des moyens de transmission au dispositif récepteur (009) de paquets de données préalablement décryptés, avec la première clé de cryptage, et cryptés selon la seconde clé de cryptage, par un n u̇d de transcription
    (0052) mettant en u̇vre une phase de cryptage/décryptage selon le protocole de protection de contenu.
    33. N u̇d récepteur selon la revendication 32 caractérisé en ce que le n u̇d récepteur (004) et le n u̇d de transcription (0052) sont confondus, en ce qu'il comprend également des moyens de substitution de paramètres initialement reçus du n u̇d d'authentification (0051) qui coopèrent avec les moyens de réception de paramètres permettant d'obtenir une seconde clé de cryptage.
  21. 34. N u̇d récepteur selon l'une quelconque des revendications 32 à 33 caractérisé en ce qu'il est distinct du n u̇d d'authentification (0051).
  22. 35. N u̇d récepteur selon l'une quelconque des revendications 32 à 33 caractérisé en ce qu'il est confondu avec le n u̇d d'authentification (0051).
    36. N u̇d source d'un réseau de communication permettant l'échange de paquets de données entre un dispositif source (006) lié audit n u̇d source (003) et un dispositif récepteur (009) lié à un n u̇d récepteur (004), les paquets de données provenant du dispositif source (006) étant cryptés selon une première clé de cryptage, caractérisé en ce qu'il comporte :
    - des moyens de réception d'une requête d'authentification conforme à une phase d'authentification selon un protocole de protection de contenu, provenant d'un n u̇d d'authentification (0051) ;
    - des moyens de transmission de la requête d'authentification au dispositif source (006), en vue de la mise en u̇vre d'une authentification du n u̇d d'authentification (0051) par le dispositif source (006) ;
    - des moyens de réception de paramètres permettant d'obtenir la première clé de cryptage du dispositif source et des moyens de transmission de ces paramètres au n u̇d d'authentification (0051) ;
    - des moyens de réception des paquets de données cryptés avec la première clé de cryptage provenant du dispositif source (006) ;
    - des moyens de transmission au à un n u̇d de transcription (0052) mettant en u̇vre une phase de cryptage/décryptage selon le protocole de protection de contenu des paquets de données cryptés avec la première clé de cryptage afin qu'il puisse décrypter lesdites données au moyen de la première clé et ensuite les crypter au moyen d'une seconde clé de cryptage.
  23. 37. N u̇d source selon la revendication 36 caractérisé en ce que le n u̇d source (003) est distinct du n u̇d de transcription (0052).
    38. N u̇d source selon l'une des revendications 38 à 37 caractérisé en ce que le n u̇d source (003) et le n u̇d de transcription (0052) sont confondus et en ce que le n u̇d source comprend en outre : des moyens de transmission au dispositif récepteur (009) via le n u̇d récepteur de paramètres permettant d'obtenir la seconde clé de cryptage après substitution de paramètres initialement reçus du n u̇d d'authentification (0051) ; des moyens de transmission au dispositif récepteur (009) via le n u̇d récepteur des données cryptées avec la seconde clé.
  24. 39. N u̇d source selon l'une quelconque des revendications 36 à 38 caractérisé en ce que le n u̇d source (003) est distinct du n u̇d d'authentification
    (0051 ).
    40. N u̇d source selon l'une quelconque des revendications 36 à 38 caractérisé en ce que le n u̇d source (003) et le n u̇d d'authentification (0051) sont confondus.
  25. 41. N u̇d d'authentification d'un réseau de communication permettant l'échange de paquets de données entre un dispositif source (006) lié à un n u̇d source (003) et un dispositif récepteur (009) lié au n u̇d récepteur (004), les paquets de données provenant du dispositif source (006) étant cryptés selon une première clé de cryptage, caractérisé en ce qu'il comporte : des premiers moyens d'authentification selon un protocole de protection de contenu afin d'authentifier le dispositif récepteur (009) via le n u̇d récepteur (004) ; des moyens de transmission de paramètres permettant d'obtenir une seconde clé de cryptage à un n u̇d de transcription (0052) mettant en u̇vre une phase de cryptage/décryptage selon le protocole de protection de contenu ; des seconds moyens d'authentification selon le protocole de protection de contenu afin de s'authentifier auprès du dispositif source (006) via le n u̇d source (003) ; des moyens de transmission de paramètres permettant d'obtenir la première clé de cryptage au n u̇d de transcription (0052) ;
  26. 42. N u̇d d'authentification selon la revendication 41 caractérisé en ce qu'il est distinct du noeud de transcription.
    43. N u̇d de transcription d'un réseau de communication permettant l'échange de paquets de données entre un dispositif source (006) lié à un n u̇d source (003) et un dispositif récepteur (009) lié au n u̇d récepteur (004), les paquets de données provenant du dispositif source (006) étant cryptés selon une première clé de cryptage, caractérisé en ce qu'il comporte :
    - des moyens de réception en provenance du n u̇d d'authentification (0051) de paramètres permettant d'obtenir la première clé de cryptage ;
    - des moyens de substitution desdits paramètres par introduction de paramètres propres au n u̇d de transcription ;
    - des moyens d'envoi desdits paramètres substitués au dispositif source
    (006) via le n u̇d source (003);
    - des moyens d'obtention de la première clé de cryptage à partir desdits paramètres substitués et de paramètres reçus du dispositif source via le n u̇d source;
    - des moyens de réception des paquets de données cryptés avec la première clé provenant du dispositif source (006) via le n u̇d source (003) ;
    - des moyens de réception en provenance du n u̇d d'authentification (0051) de paramètres permettant d'obtenir une seconde clé de cryptage ;
    - des moyens de substitution desdits paramètres par introduction de paramètres propres au n u̇d de transcription ;
    - des moyens d'envoi desdits paramètres substitués au dispositif récepteur
    (009) via le n u̇d récepteur (004);
    - des moyens d'obtention de la seconde clé de cryptage à partir desdits paramètres substitués et de paramètres reçus du dispositif récepteur (009) via le n u̇d récepteur (004); des moyens de décryptage des paquets de données avec la première clé et cryptage des paquets avec la seconde clé ; des moyens de transmission des paquets de données cryptés avec la seconde clé de cryptage au dispositif récepteur (009) via le n u̇d récepteur
    (004).
  27. 44. N u̇d de transcription selon la revendication 43 caractérisé en ce qu'il est distinct du n u̇d d'authentification (0051).
FR0504943A 2005-05-17 2005-05-17 Procede d'echange de paquets de donnees dans un reseau de communication, produit programme d'ordinateur, moyen de stockage et noeuds correspondants Expired - Fee Related FR2886081B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR0504943A FR2886081B1 (fr) 2005-05-17 2005-05-17 Procede d'echange de paquets de donnees dans un reseau de communication, produit programme d'ordinateur, moyen de stockage et noeuds correspondants

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0504943A FR2886081B1 (fr) 2005-05-17 2005-05-17 Procede d'echange de paquets de donnees dans un reseau de communication, produit programme d'ordinateur, moyen de stockage et noeuds correspondants

Publications (2)

Publication Number Publication Date
FR2886081A1 true FR2886081A1 (fr) 2006-11-24
FR2886081B1 FR2886081B1 (fr) 2012-02-10

Family

ID=35266803

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0504943A Expired - Fee Related FR2886081B1 (fr) 2005-05-17 2005-05-17 Procede d'echange de paquets de donnees dans un reseau de communication, produit programme d'ordinateur, moyen de stockage et noeuds correspondants

Country Status (1)

Country Link
FR (1) FR2886081B1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040158634A1 (en) * 2002-11-27 2004-08-12 Kabushiki Kaisha Toshiba Communication scheme using outside DTCP bridge for realizing copyright protection

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040158634A1 (en) * 2002-11-27 2004-08-12 Kabushiki Kaisha Toshiba Communication scheme using outside DTCP bridge for realizing copyright protection

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HITACHI LTD ET AL: "Digital Transmission Content Protection Specification Volume 1 Revision 1. 2a (International Version)", DIGITAL TRANSMISSION CONTENT PROTECTION SPECIFICATION, XX, XX, vol. 1, no. REVISION 12a, 25 February 2002 (2002-02-25), XP002987030 *

Also Published As

Publication number Publication date
FR2886081B1 (fr) 2012-02-10

Similar Documents

Publication Publication Date Title
FR2874143A1 (fr) Procede de securisation du transfert d'un flux de donnees, produit programme d'ordinateur, moyen de stockage et noeuds correspondants
FR2880485A1 (fr) Procedes de stockage et de lecture d'un contenu, du type mettant en oeuvre un protocole de protection de contenu, dispositifs source, de stockage et recepteur correspondants.
US7349886B2 (en) Securely relaying content using key chains
EP1662788A1 (fr) Unité de traitement de données audio/vidéo numériques et méthode de contrôle d'accès audites données
FR2834406A1 (fr) Procede de mise a jour d'une liste de revocation de cles, d'appareils ou de modules non-conformes dans un systeme de diffusion securise de contenu
WO2005071963A1 (fr) Procede et systeme d'acces conditionnel applique a la protection de contenu
EP1479233B1 (fr) Dispositif de traitement et procede de transmission de donnees chiffrees pour un premier domaine dans un reseau appartenant a un second domaine
EP1479234B1 (fr) Procede de traitement de donnees chiffrees pour un premier domaine et recues dans un reseau appartenant a un second domaine
FR2986682A1 (fr) Systeme de lecture de contenu numerique et procede de lecture correspondant
EP1419640B1 (fr) Reseau numerique local, procedes d'installation de nouveaux dispositifs et procedes de diffusion et de reception de donnees dans un tel reseau
US8312166B2 (en) Proximity detection method
WO2016116681A1 (fr) Procédé de diffusion d'un contenu multimédia protégé
FR2886081A1 (fr) Procede d'echange de paquets de donnees dans un reseau de communication, produit programme d'ordinateur, moyen de stockage et noeuds correspondants
FR2879780A1 (fr) Procede de restriction de l'acces a au moins un contenu, produit programme d'ordinateur et dispositif recepteur correspondants
JP5361031B2 (ja) 暗号認証処理方法及び装置
FR2890266A1 (fr) Procede d'echange de contenus proteges contre la copie dans un reseau heterogene, produit programme d'ordinateur, moyens de stockage et noeuds correspondants
FR2877524A1 (fr) Procedes de stockage securise et de lecture securisee, produit programme d'ordinateur, moyen de stockage et systeme correspondants
FR2888354A1 (fr) Procede de modification d'un flux afin d'en restreindre l'acces, produits programme d'ordinateur, moyens de stockage noeud source et noeud recepteur correspondants.
FR2906097A1 (fr) Procedes d'echange de donnees securises, produit programme d'ordinateur, moyen de stockage et dispositifs correspondants.
FR2895183A1 (fr) Procedes de stockage et de reconstitution d'un contenu decompose sous forme de contenus intermediaires,produit programme d'ordinateur,moyen de stockage et noeuds correspondants.
EP4017015A1 (fr) Procédé et dispositif de gestion du mode de fonctionnement d'un dispositif comprenant des moyens de transfert d'une source audiovisuelle et des moyens de restitution d'un signal audio dans un système audiovisuel
EP2262237A1 (fr) Procédé de transmission de notification sur un terminal de restitution
EP2326035B1 (fr) Procédé de traitement par un module de sécurité de messages de contrôle d'accès à un contenu et module de sécurité associé
FR2843257A1 (fr) Procede et systeme d'acces conditionnel applique a la protection de contenu
FR2912590A1 (fr) Procede de transmission differee d'un contenu de donnees, produit programme d'ordinateur, moyen de stockage et systeme de transmission correspondants

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20140131