FR2874143A1 - Procede de securisation du transfert d'un flux de donnees, produit programme d'ordinateur, moyen de stockage et noeuds correspondants - Google Patents

Procede de securisation du transfert d'un flux de donnees, produit programme d'ordinateur, moyen de stockage et noeuds correspondants Download PDF

Info

Publication number
FR2874143A1
FR2874143A1 FR0408740A FR0408740A FR2874143A1 FR 2874143 A1 FR2874143 A1 FR 2874143A1 FR 0408740 A FR0408740 A FR 0408740A FR 0408740 A FR0408740 A FR 0408740A FR 2874143 A1 FR2874143 A1 FR 2874143A1
Authority
FR
France
Prior art keywords
input node
data stream
transmission
output nodes
nodes
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
FR0408740A
Other languages
English (en)
Other versions
FR2874143B1 (fr
Inventor
Pascal Lagrange
Laurent Frouin
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 FR0408740A priority Critical patent/FR2874143B1/fr
Priority to US11/190,105 priority patent/US7797755B2/en
Priority to CN200510089371.2A priority patent/CN1731719B/zh
Priority to JP2005229994A priority patent/JP4006454B2/ja
Publication of FR2874143A1 publication Critical patent/FR2874143A1/fr
Application granted granted Critical
Publication of FR2874143B1 publication Critical patent/FR2874143B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/606Protecting data by securing the transmission between two devices or processes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/4363Adapting the video or multiplex stream to a specific local network, e.g. a IEEE 1394 or Bluetooth® network
    • H04N21/43632Adapting the video or multiplex stream to a specific local network, e.g. a IEEE 1394 or Bluetooth® network involving a wired protocol, e.g. IEEE 1394
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/4367Establishing a secure communication between the client and a peripheral device or smart card
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643Communication protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/16Analogue secrecy systems; Analogue subscription systems
    • H04N7/162Authorising the user terminal, e.g. by paying; Registering the use of a subscription channel, e.g. billing
    • H04N7/163Authorising the user terminal, e.g. by paying; Registering the use of a subscription channel, e.g. billing by receiver means only
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/101Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measures for digital rights management

Abstract

L'invention concerne un procédé de sécurisation du transfert d'un flux de données depuis un dispositif émetteur (007) vers au moins un dispositif récepteur (009), via un réseau (1001) comprenant une pluralité de noeuds reliés entre eux par une pluralité de liens, le dispositif émetteur étant connecté à un noeud d'entrée (003) dans le réseau, chaque dispositif récepteur étant connecté à un noeud de sortie (004) du réseau.Selon l'invention, un tel procédé comprend les étapes suivantes :a) transmission du flux de données vers les dispositifs récepteurs à travers les noeuds de sortie associés ;b) indication par le noeud d'entrée aux noeuds de sortie que la transmission ou le maintien de la transmission du flux de données en clair nécessite l'authentification des noeuds de sortie ;c) réception par le noeud d'entrée d'au moins une requête d'authentification émise par au moins un des noeuds de sortie ;d) authentification par le noeud d'entrée des noeuds de sorties destinataires du flux de données ;e) transmission du flux de données en clair vers au plus les noeuds de sortie authentifiés et arrêt de la transmission du flux de données vers les autres noeuds de sortie.

Description

Procédé de sécurisation du transfert d'un flux de données, produit
programme d'ordinateur, moyen de stockage et noeuds 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 cDpie de données isochrones transmises entre plusieurs dispositifs terminaux dans u l 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 contenu;; 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 peu vent 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. Aux noeuds sont reliés des équipements, directement via des liens analogiques ou indirectement, par exemple, via des bus numériques série 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 Serial Bus et IEEE Std 1394a-2000, Standard for High Performance Serial Bus (Supplement) .
La figure IA 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 noeuds 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, 15C^c 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 et 150c sont reliés à des noeuds 003, 004 et 005 du réseau fédérateur 1001 par l'intermédiaire d'un unique médium, dans notre cas des câbles 151a, 151b et 151c.
Le noeud 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 noeud 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 lA 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 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 noeuds 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 oeuvre dans le réseau domestique 1000 de la figure 1.
Les noeuds 204 et 205 sont interconnectés au moyen d'un bus série IEEE1394 201. Le noeud 204 est aussi connecté à un dispositif émetteur 203 au mayen d'un bus série IEEE-1394 200, de même que le noeud 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 oeuvre 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 noeud 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 noeud 205. Une fois que ce procédé d'authentification DTCP est réalisé avec succès, le noeud 205 met en oeuvre le même procédé d'authentification avec le noeud 204.
Une fois que ce procédé d'authentification DTCP est réalisé avec succès, le noeud 204 met en oeuvre 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 oeuvre d'un cryptage du flux de données, (l'un procédé d'authentification DTCP puis d'un décryptage et ceci à chaque transmission depuis un dispositif ou noeud du réseau vers un autre dispositif ou noeud du réseau. Il conduit donc à la mise en oeuvre d'une grande quantité d'étapes gérées par un ou plusieurs logiciels et donc à une surcharge du ré:;eau dans lequel il est mis en oeuvre et à un temps de transmission des flux de données important.
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 est de fournir une technique de protection contre la copie de flux de données dans un réseau de communicîtion domestique comprenant des liens analogiques et des liens numériques de façon transparente pour les terminaux, et ceci en limitant la charge du réseau liée à cette protection.
Un autre objectif de l'invention est de mettre en oeuvre une telle technique qui permette de réduire le temps de transmission des flux de données dans un tel réseau.
L'invention a encore pour objectif de fournir une telle technique qui soit 5 sûre, simple à mettre en oeuvre 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é de sécurisation du transfert d'un flux de données depuis; un dispositif émetteur vers au moins un dispositif récepteur, via un réseau comprenant une pluralité de noeuds reliés entre eux par une pluralité de liens, le dispositif émetteur étant connecté à un noeud d'entrée dans le réseau, chaque dispositif récepteur étant connecté à un noeud de sortie du réseau.
Selon l'invention, un tel procédé comprend les étapes success ives suivantes: transmission du flux de données vers les dispositifs récepteurs à travers les noeuds de sortie associés; indication par le noeud d'entrée aux noeuds de sortie que la transmission ou le maintien de la transmission du flux de données en clair nécessite l'authentification des noeuds de sortie; réception par le noeud d'entrée d'au moins une requête d'authentification émise par au moins un desdits noeuds de sortie; authentification par le noeud d'entrée des noeuds de sorties destinataires du flux de données; transmission du flux de données en clair vers au plus les noeuds de sortie authentifiés et arrêt de la transmission du flux de données vers les autres noeuds de sortie.
Ainsi, le fait que le flux de donnée soit transmis en clair depuis le noeud d'entrée vers les noeuds de sortie préalablement authentifiés permet de s'affranchir d'une étape de cryptage du flux par le noeud d'entrée et d'une étape de décryptage du flux par les noeuds de sortie tout en assurant une protection efficace. a) b) c) d) e)
On obtient ainsi une technique de protection contre la copie du flux de donnée qui limite la charge du réseau liée à cette protection et qui permet de réduire le temps de transmission du flux dans le réseau.
L'authentification des noeuds de sortie auprès du noeud d'entrée est transparente pour les dispositifs récepteur et émetteur.
Préférentiellement, le flux de données transmis dans l'étape a) est crypté avec une première clé.
Selon un premier mode de réalisation de l'invention, le dispositif émetteur est de type numérique et il effectue le cryptage du flux de données.
Selon un second mode de réalisation de l'invention, le dispositif émetteur est de type analogique et le noeud d'entrée effectue le cryptage du flux de données.
Selon un mode de réalisation préférentiel de l'invention, la transmission du flux de données à l'étape a) est effectuée en clair entre le noeud d'entrée el les noeuds de sortie.
Selon une caractéristique avantageuse de l'invention, le dispositif émetteur est de type numérique et il effectue un cryptage préalable du flux de données i[vec une première clé.
Avantageusement, le procédé de sécurisation comprend en outre une seconde étape d'authentification du noeud d'entrée auprès du dispositif émetteur de façon à obtenir la première clé et de décrypter le flux de données pour sa transmission en clair aux noeuds de sortie.
Préférentiellement, l'indication par le noeud d'entrée est effectuée à travers une information contenue dans un champ de contrôle transporté avec le flux de données.
Selon un mode de mise en oeuvre avantageux de l'invention, l'étape d'authentification des noeuds de sorties comprend les étapes de: détermination du nombre N1 de noeuds de sorties qui ont destinataires du flux de données; - détermination du nombre N2 de requêtes de transmission en clair reçues par le noeud d'entrée et émises par lesdits noeuds de sortie; - authentification des noeuds de sorties si les nombres N1 et N2:;ont égaux.
Selon une caractéristique avantageuse de l'invention, l'étape de détermination du nombre N2 est effectuée par le comptage du nombre de requêtes de transmission en clair réellement reçues à l'issue d'une temporisation d'une durée prédéterminée.
Préférentiellement, la requête de transmission en clair comprend au moins une information permettant de quantifier un niveau d'autorisation du dispositif récepteur pour l'accès au flux de données.
Selon un mode de réalisation préférentiel de l'invention, si les noeuds de sorties ne sont pas authentifiés, le noeud d'entrée envoie une notification aux autres noeuds les informant de l'échec de l'authentification.
Selon une caractéristique avantageuse de l'invention, si le dispositif récepteur est de type numérique, le procédé comprend en outre les étapes suivantes: 1) cryptage du flux reçu par le noeud de sortie avec une seconde et: qui lui est propre; 2) transmission par le noeud de sortie du flux crypté vers le dispositif récepteur; 3) authentification du dispositif récepteur auprès du noeud de sortie de façon à obtenir la seconde clé ; 4) décryptage du flux par le dispositif récepteur avec la seconde clé.
L'invention concerne également un produit programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé de sécurisation décrit précédemment, lorsque le programme est exécuté sur un ordinateur.
L'invention concerne également un moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un système informatique comprenant des instructions pour un programme informatique adaptées à mettre en oeuvre le procédé de sécurisation décrit précédemment.
L'invention concerne également un noeud d'entrée impliqué dam; un transfert sécurisé d'un flux de données depuis un dispositif émetteur vers au moins un dispositif récepteur via un réseau comprenant une pluralité de noeuds reliés entre eux par une pluralité de liens, le dispositif émetteur étant connecté au noeud d'entrée dans le réseau, chaque dispositif récepteur étant connecté à un noeud de sortie du réseau, le noeud d'entrée comprenant: a) des moyens de transmission du flux de données vers les dispositifs récepteurs à travers les noeuds de sortie associés; b) des moyens d'indication aux noeuds de sortie que la transmission ou le maintien de la transmission du flux de données en clair nécessite l'authentification des noeuds de sortie; c) des moyens de réception d'au moins une requête d'authentification émise par au moins un des noeuds de sortie; d) des moyens d'authentification des noeuds de sorties destinataires du flux de données de sorte que le flux de données soit transmis en clair, par les moyens de transmission, vers au plus les noeuds de sortie authentifiés; Selon un mode de mise en oeuvre avantageux de l'invention, le noeud d'entrée coopère avec des moyens de cryptage du flux de données, les moyens de cryptage mettant en oeuvre une première clé.
Avantageusement, les moyens de cryptage sont hébergés par le dispositif émetteur, ce dernier étant de type numérique.
Selon une caractéristique préférentielle de l'invention, le noeud d'entrée intègre les moyens de cryptage, le dispositif émetteur étant de type analogique. Préférentiellement, le flux de données transmis par les moyens de transmission est un flux de données en clair.
Selon un mode de mise en oeuvre avantageux de l'invention, le dispositif émetteur est de type numérique et comprend des moyens de cryptage du flux de données au moyen d'une première clé.
Selon un mode de réalisation préférentiel de l'invention, le noeud d'entrée comprend en outre des seconds moyens d'authentification auprès du dispositif émetteur de façon à obtenir la première clé et des moyens de décryptage du flux 15 de données.
Préférentiellement, les moyens d'indication coopèrent avec une information comprise dans un champ de contrôle transporté avec le flux de données.
Selon une caractéristique avantageuse de l'invention, les moyens d'authentification des noeuds de sorties comprennent: des moyens de détermination du nombre N1 de noeuds de sortie qui sont destinataires du flux de données; des moyens de détermination du nombre N2 de requêtes de transmission en clair reçues par le noeud d'entrée et émises pal les noeuds de sortie; des moyens de comparaison des nombres N1 et N2.
Avantageusement, les moyens de détermination du nombre N2 comprennent des moyens de comptage du nombre de requêtes de transmissio n en clair réellement reçues à l'issue d'une temporisation d'une durée prédéterminée.
Selon un mode de mise en oeuvre avantageux de l'invention, la requête de transmission en clair comprend au moins une information permettant de quantifier un niveau d'autorisation du dispositif récepteur pour l'accès au flux de données.
Avantageusement, le noeud d'entrée comprend des moyens de transmission aux autres noeuds d'une notification d'échec d'authentification, ces moyens Étant activés si les noeuds de sorties ne sont pas authentifiés.
L'invention concerne également un noeud de sortie impliqué dam un transfert sécurisé d'un flux de données depuis un dispositif émetteur vers au moins un dispositif récepteur via un réseau comprenant une pluralité de noeuds reliés entre eux par une pluralité de liens, le dispositif émetteur étant connecté à un noeud d'entrée dans le réseau, chaque dispositif récepteur étant connectê au noeud de sortie du réseau caractérisé en ce que le noeud de sortie comprend - des moyens de réception du flux de données à partir du noeud d'entrée; - des moyens de réception d'une information indiquant que la réception ou le maintien de la réception du flux de données en clair nécessite l'authentification des noeuds de sortie; - des moyens de transmission d'une requête d'authentification au noeud d'entrée.
5. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels: la figure lA présente le schéma d'un réseau audio-vidéo domestique dans lequel peut être mis en oeuvre 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 oeuvre 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'un noeud d'un réseau domestique dans lequel est mis en oeuvre le procédé de l'invention; les figures 4A, 4B et 4C présentent des algorithmes du procédé selon l'invention permettant de piloter les flux de données isochrones protégés contre la copie transmis dans le réseau domestique au niveau composant (figure 4A) et au niveau logiciel (figures 4B et 4C) ; la figure 5 présente un quatrième algorithme du procédé selon l'invention permettant de piloter les flux de données isochrones protégés contre la copie transmis dans le réseau domestique au niveau logiciel; - la figure 6 illustre le procédé de transmission sécurisé entre un dispositif émetteur et un dispositif récepteur dans le cas illustré par la figure 11, où les liens de connexion de ces dispositifs aux noeuds d'entrée et de sortie sont des liens numériques; la figure 7 illustre le procédé de transmission sécurisé entre un dispositif émetteur et un dispositif récepteur dans le cas illustré par la figure 1A où le liens de connexion entre le dispositif émetteur et le noeud d'entrée est analogique alors que le lien de connexion entre le dispositif récepteur et le noeud de sortie est un lien numérique.
6. Description d'un mode de réalisation de l'invention Le principe général de l'invention repose sur l'envoi d'une requête en clair par un noeud de sortie auquel est connecté un dispositif récepteur d'un contenu vers un noeud d'entrée auquel est connecté un dispositif émetteur visant à ce que le noeud d'entrée transmette le contenu à protéger contre la copie en clair dans un réseau fédérateur comprenant les noeuds d'entrée et sortie.
On se place dans la suite dans le cadre du réseau audio-vidéo domestique 1000 de la figure lA dans lequel est mis en oeuvre le procédé de sécurisation selon un mode de réalisation préférentiel de l'invention.
Ce procédé de sécurisation est, selon ce mode de réalisation préférentiel de l'invention, un procédé de protection contre la copie et 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) dans une ou plusieurs machines du réseau.
On présente, en relation avec la figure 3, le schéma d'une implémentttion d'un noeud 100 du réseau domestique 1000 selon un mode de mise en oeuvre particulier de l'invention. On ne décrit, par soucis de simplicité, que ce noeud de générique 100 qui représente aussi bien le noeud 003 que le noeud 004 ou même le noeud 005 du réseau domestique 1000.
Le noeud 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 Rai, Sal et Sa2 via des liens analogiques. Le noeud 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 noeud 100, une mémoire tampon de transmission 103 mise- en oeuvre 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 oeuvre 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 phys que 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 noeud 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 Rai, Sal et Sa2.
Un module de contrôle de transition 114 assure: - la mise en oeuvre 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 Serial Bus Bridges ) dont notamment: - la surveillance des paquets arrivant; la génération d'accusés de réception; 30 - 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 135; - la mise en oeuvre 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 noeud 100 comprend un module de décryptage à 4 clés 115 qui met en oeuvre l'algorithme de décryptage et qui fournit aussi 5 registres de configuraion de clé indépendants.
Il comprend un module de cryptage à 1 clé 116 qui met en oeuvre l'algorithme de cryptage et qui fournit aussi 1 seul registre de configuration de clé de cryptage.
Un module FIFO ( First in First out en anglais ou premier entré 25 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 noeud 100 comprend également un module de détection de protection 30 contre la copie 119 qui détecte les droits de protection contre la copie au moyen 10 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 la suite, on va se placer (sauf indication contraire) dans un mode de réalisation préférentiel de l'invention selon lequel, on a une transmission, dans le réseau domestique 1000 de la figure 1A, d'un flux de données isochrones comprenant un contenu protégé contre la copie, par exemple un contenu au lio- vidéo. Plus précisément, le flux isochrone est transmis depuis un dispositif émetteur 007 noté S3 vers un dispositif récepteur 009, noté R3, via le ré;eau fédérateur 1001. A cet effet, le dispositif émetteur 007 est connecté à un noeud d'entrée 003 dans ce réseau fédérateur 1001 et le dispositif récepteur 009, est connecté à un noeud de sortie 004 du 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 noeud de sortie du réseau. Plusieurs dispositifs récepteurs peuvent éventuellement être connectés à un même noeud de sortie du réseau.
Bien entendu, dans la pratique, un même noeud peut jouer le rôle d'un noeud d'entrée si au moins un dispositif émetteur lui est connecté et/ou le rôle d'un noeud de sortie si un dispositif récepteur lui est connecté. De la même manière, un même dispositif pourra être récepteur dans certaines transmission, de données et émetteur dans d'autres transmissions de données.
Les figures 4A et 4B présentent un premier et un second algorithme du procédé selon l'invention permettant de piloter le flux de données isochrones transmis à travers le réseau domestique 1000.
Le premier algorithme (figure 4A), mis en oeuvre à un niveau composant, ainsi que le second algorithme (figure 4B), mis en oeuvre à un niveau logiciel, font intervenir essentiellement le noeud de sortie 004.
Lorsque le noeud de sortie 004, noté NB, reçoit le flux isochrone provenant du réseau domestique 1000, son module de détection de protection contre la copie 119 vérifie dans une étape 300 si le flux doit être crypté ou non. Pour ce faire, il analyse les bits EMI contenus dans l'en-tête despaquets du flux isochrone. Si les bits EMI sont égaux à une valeur prédéterminée (selon la spécification ci-dessus une valeur non nulle), cela veut dire que le flux a suti un premier cryptage au moyen d'une première clé lors de son émission du dispositif émetteur, et qu'il doit donc également subir un second cryptage, au moyen d'une seconde clé, lors de sa transmission au dispositif récepteur. Lors do sa transmission à travers le réseau domestique le flux peut être maintenu crypté suite au premier cryptage ou décrypté et transmis en claire sur le réseau domestique. La décision du maintien du cryptage ou de la transmission en clair est prise selon que la transmission du flux est effectuée pour la première fois, ou si le dispositif récepteur veut recevoir un flux qui est déjà transmis en clair à travers le ré ;eau domestique pour d'autres dispositifs récepteurs. Il faut noter que dans les cieux cas, le noeud d'entrée n'a pas à effectuer de cryptage du flux de données ce qui a l'avantage de réduire la charge de traitement de ce noeud.
Si le flux ne doit pas être crypté (la valeur des bits EMI est nulle), cela signifie qu'il est accessible en copie par tout appareil implémentant ou ncn le protocole DTCP. Il n'y a donc pas lieu d'effectuer un second cryptage.
Si le flux doit être crypté, dans une étape 301, le noeud de sortie 004 obtient la liste des dispositifs récepteurs du flux (qui écoutent le canal utilisé pour la transmission du flux isochrone protégé par cryptage) qui lui sont connectés et dont notamment le dispositif récepteur 009.
Dans une étape 302, le module de cryptage 116 du noeud de sortie 004 est initialisé pour le canal de transmission du contenu afin de mettre en oeuvre un second cryptage du flux isochrone à l'aide d'une seconde clé propre au noeud de sortie 004. Enfin, dans une étape 303, le module de détection de protection contre la copie 119 du noeud de sortie 004 notifie au logiciel et/ou aux sous logiciels selon l'invention le fait que le canal de transmission est utilisé pour le transfert d'un contenu protégé contre la copie.
Au niveau logiciel, dans une étape 304, le logiciel (et/ou les sous logiciels) selon l'invention est prévenu par le niveau composant qu'un cana, de transmission donné est utilisé pour le transfert d'un contenu protégé contre la copie. Il obtient consécutivement, dans une étape 305, un identifiant du noeud d'entrée 003 auquel est connecté le dispositif émetteur 007 du flux isochrone. Dans une étape 306, les droits de protection contre la copie, propres au noeud de sortie 004, quantifiant son niveau d'autorisation d'accès aux différents dispositifs connectés au réseau, sont obtenus.
Le noeud de sortie 004 va chercher, dans un espace mémoire interne lui étant propre, ses propres droits de protection contre la copie. Selon une variante de ce mode de réalisation préférentiel, tous les noeuds connectés au réseau ont connaissance des droits de protection contre la copie de chacun des autres noeuds du réseau.
Dans une étape 307, pour l'ensemble des dispositifs récepteurs connectés au noeud de sortie 004 et notamment pour le dispositif récepteur 009, une requête de transmission en clair comprenant les droits de protection contre la copie relatifs au noeud de sortie 004 est envoyée par le noeud de sortie 004 au n eud d'entrée 003.
La figure 4C présente un troisième algorithme du procédé scion l'invention permettant de piloter le flux de données isochrones protégées contre la copie transmis dans le réseau domestique 1000. Cet algorithme, mis en oeuvre à un niveau logiciel, fait intervenir essentiellement le noeud d'entrée 003.
Lorsqu'il reçoit une requête de transmission en clair, par exemple concernant le dispositif récepteur 009, dans une étape 308, le noeud d'entrée 003 extrait, dans une étape 309, le numéro du canal isochrone de transmission utilisé ainsi que les droits de protection contre la copie associés à la requête. Ensuite, les droits de protection contre la copie sont inspectés dans les étapes 310 et 311.
Si les droits n'autorisent pas le dispositif récepteur 009 connecté au noeud de sortie 004 à accéder au contenu protégé, dans une étape 312, le noeud d'entrée 003 vérifie s'il est en train de décrypter le flux comprenant le contenu protée au moyen de la première clé. Si c'est le cas, dans une étape 313, le noeud d'entrée 003 arrête le décryptage du flux associé au numéro de canal isochrone précédemment extrait. Une fois que le module de décryptage 115 est arrêté cu si le noeud d'entrée 003 n'est pas en train de décrypter le flux, il met en oeuvre l'étape 314 dans laquelle il notifie au noeud de sortie 004, ayant émis la requête, que la requête concernant le dispositif récepteur 009 est rejetée. Ensuite, le noeud d'entrée 003 met fin à la procédure, dans une étape 315.
Si les droits de protection contre la copie autorisent le dispositif récepteur 009 à accéder au contenu protégé, le noeud d'entrée 003 vérifie dans une étape 316 si le flux correspondant est déjà décrypté. Si c'est le cas, le noeud d'entrée 003 remet en oeuvre l'étape 308.
Dans le cas, illustré par la figure lA, où le dispositif émetteur 007 est connecté au noeud d'entrée 003 au moyen d'une connexion numérique, par exemple via un bus IEEE-1394, si le flux correspondant n'est pas déjà décrypté, dans une étape 317, le noeud d'entrée 003 extrait du canal isochrone l'identifiant du dispositif émetteur 007 du flux isochrone et met en oeuvre le procédé d'authentification DTCP auprès du dispositif émetteur 007 dans une étape 318.
Une fois que, dans une étape 319 le noeud d'entrée 003 a reçu la première clé de décryptage du dispositif émetteur 007 (clé qui a préalablement servi au dispositif émetteur 007 pour réaliser le premier cryptage du flux isochrone), clans une étape 320, le module de décryptage du noeud d'entrée 003 est initialisé avec la première clé de manière à décrypter le flux sur le canal isochrone. Ensuite, le noeud d'entrée 003 attend l'arrivée d'une nouvelle requête pour remettre en oeuvre l'étape 308.
Dans le cas, non illustré, où le dispositif émetteur 007 (de type analogique) est connecté au noeud d'entrée 003 au moyen d'une connexion analogique, le module de décryptage du noeud d'entrée 003 (qui a préalablement réalisé lui-même le premier cryptage au moyen de sa propre clé) est initialisé .vec la première clé, qui est sa propre clé, de manière à décrypter le flux sur le canal isochrone. Ensuite, le noeud d'entrée 003 attend l'arrivée d'une nouvelle requête pour remettre en oeuvre l'étape 308.
Lorsque le flux est décrypté par le noeud d'entrée pour être transmis en clair sur le réseau domestique, la valeur des bits EMI doit être maintenue avec leur valeur initiale (non nulle) pour indiquer au noeud de sortie que ce flux doit être encrypté lors de son émission vers le dispositif récepteur.
En parallèle avec le troisième algorithme de la figure 4C, le logiciel et/ou les sous logiciels selon l'invention met en oeuvre un quatrième algorithme, illustré par la figure 5, du procédé selon l'invention. Cet algorithme permet l'authentification des noeuds de sorties, et donc de conditionner l'étape de décryptage 320 du flux de données isochrones de la figure 4C à la réception d'un nombre adéquat de requêtes de transmission en clair. Cet algorithme, mis en oeuvre à un niveau logiciel, fait intervenir essentiellement le noeud d'entrée 00_,.
Lorsque dans une étape 400, une connexion de flux isochrone est établie dans le réseau domestique 1000 afin de transmettre le contenu protégé, le noeud d'entrée 003 analyse une en-tête de routage des paquets du flux isochrone reçu dans une étape 401. Cette en-tête peut être rajoutée aux paquets afin d'assurer le transport des paquets isochrones sur le réseau. Le noeud d'entrée 003 en extrait dans une étape 402 le nombre, noté Nc, de noeuds du réseau domestique 1000 auxquels sont connectés des dispositifs récepteurs du flux (qui écoutent le canal utilisé pour la transmission du flux isochrone).
Ensuite, le logiciel (et/ou les sous logiciels) selon l'invention met en oeuvre une étape 403 de mise en attente pendant laquelle le noeud d'entrée 003 attend qu'une temporisation expire au bout d'un délai. Ce délai est défini comme étant le délai maximum nécessaire pour que chacun des noeuds du réseau domestique 1000 puisse émettre une requête de transmission en claire a)rès avoir reçu et détecté un flux isochrone crypté.
Dans une étape 404, une fois que ce délai ou cette temporisation a expiré, le nombre de requêtes de transmission en claire réellement reçues est analysé par le logiciel et/ou les sous logiciels selon l'invention. Si ce nombre est égal au nombre, noté Nc, de noeuds du réseau domestique 1000 auxquels sont connectés des dispositifs récepteurs du flux (c'est-à- dire au nombre de requêtes en clair attendues), le logiciel (et/ou les sous logiciels) selon l'invention remet en oeuvre l'étape initiale 400 de ce quatrième algorithme.
Si ce nombre n'est pas égal au nombre de noeuds du réseau domestique 1000 auxquels sont connectés des dispositifs récepteurs du flux, cela peut signifier qu'un dispositif non autorisé a été introduit dans le réseau domestique 1000 et essaie d'accéder de manière illégale au contenu protégé par cryptage. Ainsi, dans une étape 405, le noeud d'entrée 003 arrête immédiatement tous les processus de décryptage de flux isochrones en cours et notifie cet échec d'authentification à tous les noeuds connectés du réseau domestique 1000 dans une étape 406. Le logiciel (et/ou les sous logiciels) selon l'invention remet ensuite en oeuvre l'étape initiale 400 de ce quatrième algorithme.
Dans une variante de réalisation de l'invention, le logiciel met en oeuvre des moyens pour déterminer les noeuds de sortie qui ont transmis des requêtes de transmission en clair parmi l'ensemble des noeuds de sortie destinataires. Ainsi, il est possible d'authentifier une partie seulement des noeuds de sortie. Dans cette variante de réalisation, le noeud d'entrée peut continuer à transmettre le flux de données décrypté seulement vers les noeuds de sortie authentifiés. Ceci peut être réalisé en modifiant la connexion par changement de l'en-tête de routage par exemple.
Lorsque la connexion est déjà établie vers un ou plusieurs noeuds de sorties et qu'un ou plusieurs nouveau(x) dispositif(s) récepteur(s) connectés) à des noeuds de sortie différents veulent également recevoir le flux isochrone, il faut modifier la connexion existante pour desservir ce(s) nouveau(x) récepteur(s) (fonction foin en anglais).
L'algorithme d'authentification des nouveaux noeuds de sortie dan; ce cas là est similaire à celui décrit en rapport avec la figure 5. Le noeud d'entrée exécutera les mêmes étapes 401, 402, 403 et 404. La différence est que le noeud d'entrée transmet déjà le flux en clair sur le réseau domestique pour les autres dispositifs récepteurs. Le noeud d'entrée va continuer à transmettre le flux en clair jusqu'à l'authentification des noeuds de sortie nouvellement impliqués. Si l'authentification échoue, le noeud d'entrée arrêtera le décryptage du flux vers au moins les noeuds de sorties qui n'ont pas été authentifiés.
D'autre part, dans le cas où plusieurs dispositifs récepteurs reçoivent le flux isochrone, il est possible qu'une partie de ces récepteurs veuillent arrêter la réception du flux. Si des noeuds de sortie ne possèdent plus de dispositifs récepteurs destinataires de ce flux, la connexion est modifiée pour ne plus desservir ces noeuds. Il n'est pas nécessaire pour les noeuds de sorties dans ce cas là de transmettre des requêtes spécifiques.
La figure 6 illustre le pilotage par le logiciel et/ou les sous logiciels selon l'invention de la transmission sécurisée du flux isochrone entre le dispositif émetteur 007 noté S3 et le dispositif récepteur 009 noté R3 dans le cas illustré par la figure lA où les liens de connexion de ces dispositifs aux noeuds d'entrée 003, noté NA, et de sortie 004, noté NB, sont des liens numériques respectant la norme IEEE-1394.
Le dispositif émetteur 007 commence à envoyer un flux isochrone dans un canal sur le réseau domestique 1000 de la figure lA dont le contenu 503 a été préalablement crypté au moyen d'une première clé, sa propre clé de cryptage 504 notée key(S3).
On peut tout d'abord noter qu'avant que le noeud de sortie 004 transmette ce flux isochrone sur un bus IEEE-1394 002, notamment vers le dispositif récepteur 009, il effectue tout d'abord un second cryptage au moyen d'une seconde clé qui est sa propre clé 506 notée key(NB). Ainsi, le flux isochrone qui sera envoyé sur le bus IEEE-1394 est un flux 505 crypté deux fois, ou doublement crypté.
A la réception du flux 503 simplement crypté, le noeud de sortie 004 vérifie si certains des dispositifs qui lui sont connectés sont à l'écoute du canal du flux isochrone. Notamment, le dispositif récepteur 009 est l'un d'entre eux. Alors, le noeud de sortie 004 met en oeuvre et envoie une requête de transmission en clair 500 au noeud d'entrée 003. Le noeud d'entrée 003 vérifie les droits de protection contre la copie associés à la requête en clair 500.
Si les droits sont valables, le noeud d'entrée 003 met en oeuvre un procédé d'authentification DTCP auprès du dispositif émetteur 007 (comprenant une requête d'authentification 501 et sa réponse 502). Il obtient ainsi la première clé 504 qu'a préalablement utilisé le dispositif émetteur 007 pour réaliser le premier cryptage du flux isochrone.
Ensuite, le noeud d'entrée 003 utilise la première clé 504 afin de décrypter le flux isochrone 503 qui n'a jusqu'alors subi que le premier cryptage. Ainsi, le flux 510 est envoyé en clair entre le noeud d'entrée 003 et le noeud de sortie 004 dans réseau fédérateur 1001.
Lorsqu'il sort du réseau fédérateur 1001, pour atteindre le dispositif récepteur 009, le flux isochrone est crypté par le noeud de sortie 004 au moyen de la seconde clé 506, comme expliqué précédemment. Ainsi, lorsqu'il reçoit le flux crypté 509 auquel il souhaite accéder, le dispositif récepteur 009 met en oeuvre un procédé d'authentification DTCP auprès du noeud de sortie 004 (comprenant une requête d'authentification 507 et sa réponse 508). Il obtient ainsi la seconde clé 506.
Ensuite, le dispositif 009 utilise la seconde clé 506 afin de décrypter le flux isochrone 509 qui n'est plus alors crypté qu'au moyen de la seconde clé.
Ainsi, le flux résultant de ce second décryptage est un flux non crypté et le dispositif récepteur 009 peut accéder au contenu compris dans ce flux.
Si les droits de protection contre la copie associés à la requête en clair 500 n'autorisent pas le dispositif récepteur 009 à accéder au contenu (les droits ne sont pas valables), le noeud d'entrée 003 ne met pas en oeuvre le premier décryptage du flux isochrone 503 qui n'a jusqu'alors subi que le premier cryptage.
Ainsi, le flux 503 est transmis crypté au moyen de la première clé 504 entre le noeud d'entrée 003 et le noeud de sortie 004 dans réseau fédérateur 1001.
Ensuite, lorsqu'il reçoit le flux doublement crypté 505 auquel il soulaite accéder, le dispositif récepteur 009 met en oeuvre un procédé d'authentification DTCP auprès du noeud de sortie 004 (comprenant une requête d'authentification 507 et sa réponse 508). Il obtient ainsi la seconde clé 506 qui lui permet de décrypter partiellement le flux isochrone. Cependant le flux 503 résultant de ce décryptage partiel reste crypté au moyen de la première clé 504. Ainsi, le dispositif récepteur 009 ne peut pas accéder au contenu compris dans le flux résultant 503.
On peut noter que lors de la transmission à travers le réseau fédérateur 1001 d'un flux isochrone, entre le dispositif émetteur 007 et le dispositif récepteur 009, selon le procédé de sécurisation de l'invention, il n'est mis en oeuvre que deux procédés d'authentification DTCP. La mise en oeuvre du protocole DTCP selon l'art antérieur dans ce contexte aurait nécessité trois tels procédés d'authentification DTCP. Ainsi, le procédé selon l'invention permet de limiter la charge du réseau liée à la protection contre la copie et de réduire le temps de transmission des flux isochrones protégés.
La figure 7 illustre le pilotage par le logiciel et/ou les sous logiciels selon l'invention de la transmission sécurisée du flux isochrone entre un dispcsitif émetteur 013, noté Sal, et le dispositif récepteur 009, noté R3, dans le cas illustré par la figure lA où le liens de connexion entre le dispositif émetteur 013 et le noeud d'entrée 003, noté NA, est analogique alors que le lien de connexion entre le dispositif récepteur 009 et le noeud de sortie 004, noté N13, est un lien numérique.
Lorsque le noeud d'entrée 003 détecte la nécessité de protection contre la copie (par exemple l'activation de moyens anti-reproduction selon le système "macrovision", système conçu et développé par la société MACROVISION, marque déposée) d'un contenu envoyé par le dispositif émetteur 013 analogique, il commence à mettre en oeuvre un premier cryptage de ce contenu au moyen d'une première clé, sa propre clé de cryptage notée key(NA). Puis, il envoie le contenu sur le réseau fédérateur 1001 dans un flux isochrone 601.
On peut noter qu'avant de transmettre ce flux isochrone sur un bus IEEE1394 002, notamment vers le dispositif récepteur 009, le noeud de sortie 004 effectue tout d'abord un second cryptage au moyen d'une seconde clé qui est sa propre clé 606 notée key(NB). Ainsi, le flux isochrone qui sera envoyé sur le bus IEEE-1394 est un flux 603 crypté deux fois, ou doublement crypté.
A la réception du flux 601 simplement crypté, le noeud de sortie 004 vérifie si certains des dispositifs qui lui sont connectés sont à l'écoute du canal du flux isochrone. Notamment, le dispositif récepteur 009 est l'un d'entre eux. A ors, le noeud de sortie 004 met en oeuvre et envoie une requête de transmission en clair 600 au noeud d'entrée 003. Le noeud d'entrée 003 vérifie les droit; de protection contre la copie associés à la requête en clair 600.
Si les droits sont valables, le noeud d'entrée 003 arrête le premier cryptage du contenu envoyé par le dispositif émetteur 013 analogique. Ainsi, le flux 610 est envoyé en clair entre le noeud d'entrée 003 et le noeud de sortie 004 dans réseau fédérateur 1001.
Lorsqu'il sort du réseau fédérateur 1001, pour atteindre le dispositif récepteur 009, le flux isochrone est crypté par le noeud de sortie 004 au moyen de la seconde clé 606, comme expliqué précédemment. Ainsi, lorsqu'il reçoit le flux crypté 609 auquel il souhaite accéder, le dispositif récepteur 009 met en oeuvre un procédé d'authentification DTCP auprès du noeud de sortie 004 (comprenant une requête d'authentification 604 et sa réponse 605). Il obtient ainsi la seconde clé 606.
Ensuite, le dispositif 009 utilise la seconde clé 606 afin de décrypter le flux isochrone 609 qui n'est plus alors crypté qu'au moyen de la seconde clé. Ainsi, le flux résultant de ce second décryptage est un flux non crypté et le dispositif récepteur 009 peut accéder au contenu compris dans ce flux.
Si les droits de protection contre la copie associés à la requête en zlair 600 n'autorisent pas le dispositif récepteur 009 à accéder au contenu (les droits ne sont pas valables), le noeud d'entrée 003 n'arrête pas le premier cryptage du contenu envoyé par le dispositif émetteur 013. Ainsi, le flux 601 est transmis crypté au moyen de la première clé key(NA) entre le noeud d'entrée 003 et le noeud de sortie 004 dans réseau fédérateur 1001.
Ensuite, lorsqu'il reçoit le flux doublement crypté 603 auquel il souhaite accéder, le dispositif récepteur 009 met en oeuvre un procédé d'authentifica:ion DTCP auprès du noeud de sortie 004 (comprenant une requête d'authentification 604 et sa réponse 605). Il obtient ainsi la seconde clé 606 qui lui permet de décrypter partiellement le flux isochrone. Cependant le flux 601 résultant de ce décryptage partiel reste crypté au moyen de la première clé key(NA). Ainsi, le dispositif récepteur 009 ne peut pas accéder au contenu compris dans le Flux résultant 601.
On peut noter que lors de la transmission à travers le réseau fédérateur 1001 d'un flux isochrone, entre le dispositif émetteur 013 et le dispositif récepteur 009, selon le procédé de sécurisation de l'invention, il n'est mis en oeuvre qu'un seul procédé d'authentification DTCP. La mise en oeuvre du protocole DTCP selon l'art antérieur dans ce contexte aurait nécessité deux tels procédés d'authentification DTCP. Ainsi, le procédé selon l'invention permet de limiter la charge du réseau liée à la protection contre la copie et de réduire le temps de transmission des flux isochrones protégés.

Claims (28)

REVENDICATIONS
1. Procédé de sécurisation du transfert d'un flux de données depuis un dispositif émetteur (007) vers au moins un dispositif récepteur (009), vin un réseau (1001) comprenant une pluralité de noeuds reliés entre eux par une pluralité de liens, le dispositif émetteur étant connecté à un noeud d'entrée (003) dans le réseau, chaque dispositif récepteur étant connecté à un noeud de sortie (004) du réseau, caractérisé en ce qu'il comprend les étapes suivantes: a) transmission du flux de données vers les dispositifs récepteurs à travers les noeuds de sortie associés; b) indication par le noeud d'entrée (003) aux noeuds de sortie que la transmission ou le maintien de la transmission du flux de don zées en clair nécessite l'authentification des noeuds de sortie; c) réception par le noeud d'entrée d'au moins une req fête d'authentification émise par au moins un desdits noeuds de sortie; d) authentification par le noeud d'entrée (003) des noeuds de sorties destinataires du flux de données; e) transmission du flux de données en clair vers au plus les noeuds de sortie authentifiés et arrêt de la transmission du flux de données vers les autres noeuds de sortie.
2. Procédé selon la revendication 1, caractérisé en ce que le flux de données transmis dans l'étape a) est crypté avec une première clé.
3. Procédé selon la revendication 2, caractérisé en ce que le dispositif émetteur (007) est de type numérique et en ce que c'est ce dispositif émetteur qui effectue le cryptage du flux de données.
4. Procédé selon la revendication 2, caractérisé en ce que le dispositif émetteur (007) est de type analogique et en ce que c'est le noeud d'entrée (D03) qui effectue le cryptage du flux de données.
5. Procédé selon la revendication 1, caractérisé en ce que la transmission du flux de données à l'étape a) est effectuée en clair entre le noeud d'entrée (003) et les noeuds de sortie.
6. Procédé selon la revendication 5, caractérisé en ce que le dispositif émetteur (007) est de type numérique et en ce que ce dispositif émetteur effectue un cryptage préalable du flux de données avec une première clé.
7. Procédé selon la revendication 6, caractérisé en ce qu'il comprend en outre une seconde étape d'authentification du noeud d'entrée (003) auprès du dispositif émetteur (007) de façon à obtenir la première clé et de décrypter le flue. de données pour sa transmission en clair auxdits noeuds de sortie.
8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que l'indication par le noeud d'entrée (003) est effectuée à travers une information contenue dans un champ de contrôle transporté avec le flux de données.
9. Procédé selon l'une quelconque des revendications 1 à 8 caractérisé en ce que l'étape d'authentification des noeuds de sorties comprend les étapes de: - détermination du nombre N1 de noeuds de sorties qui;ont destinataires du flux de données; détermination du nombre N2 de requêtes de transmission en clair reçues par le noeud d'entrée (003) et émises par lesdits noeuds de sortie; authentification des noeuds de sorties si les nombres N1 et N2 sont égaux.
10. Procédé selon la revendication 9 caractérisé en ce que ladite étape de détermination du nombre N2 est effectuée par le comptage du nombre de requêtes de transmission en clair réellement reçues à l'issue d'une temporisation d'une durée prédéterminée.
11. Procédé selon l'une quelconque des revendications 1 à 10 caractérisé en ce que la requête de transmission en clair comprend au moins une information permettant de quantifier un niveau d'autorisation dudit dispositif récepteur pour l'accès audit flux de données.
12. Procédé selon l'une quelconque des revendications 9 à 11 caractérisé on ce que si les noeuds de sorties ne sont pas authentifiés, le noeud d'entrée (003) envoie une notification aux autres noeuds les informant de l'échec de l'authentification.
13. Procédé selon l'une quelconque des revendications 1 à 12, caractérise: en ce que si le dispositif récepteur est de type numérique, le procédé comprend en outre les étapes suivantes: 1) cryptage du flux reçu par le noeud de sortie avec une seconde clé qui lui est propre; 2) transmission par le noeud de sortie du flux crypté vers le dispositif récepteur; 3) authentification du dispositif récepteur auprès du noeud de sortie de façon à obtenir la seconde clé ; 4) décryptage du flux par le dispositif récepteur avec la seconde clé.
14. 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é de sécurisation selon l'une quelconque des revendications 1 à 13, lorsque ledit programme est exécuté sur un ordinateur.
15. Moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un système informatique, caractérisé e n ce qu'il comprend des instructions pour un programme informatique adaptées à mettre en oeuvre le procédé de sécurisation selon l'une quelconque des revendications 1 à 13, lorsque ledit programme est exécuté sur un ordinateur.
16. Noeud d'entrée impliqué dans un transfert sécurisé d'un flux de données depuis un dispositif émetteur (007) vers au moins un dispositif récepteur (C09), via un réseau (1001) comprenant une pluralité de noeuds reliés entre eux par une pluralité de liens, le dispositif émetteur étant connecté audit noeud d'entrée dans le réseau, chaque dispositif récepteur étant connecté à un noeud de sortie (004) du réseau caractérisé en ce que ledit noeud d'entrée comprend: a) des moyens de transmission du flux de données vers les dispositifs récepteurs à travers les noeuds de sortie associés; b) des moyens d'indication aux noeuds de sortie que la transmission ou le maintien de la transmission du flux de données en clair nécessite l'authentification des noeuds de sortie; c) des moyens de réception d'au moins une requête d'authentification émise par au moins un desdits noeuds de sortie; d) des moyens d'authentification des noeuds de sorties destinataires du flux de données de sorte que le flux de données soit transmis en clair, par les moyens de transmission, vers au plus les noeuds de sortie authentifiés;
17. Noeud d'entrée selon la revendication 16, caractérisé en ce qu'il coopère avec des moyens de cryptage du flux de données, lesdits moyens de cryptage mettant en oeuvre une première clé.
18. Noeud d'entrée selon la revendication 17, caractérisé en ce que les moyens de cryptage sont hébergés par ledit dispositif émetteur (007), ce dernier étant de type numérique.
19. Noeud d'entrée selon la revendication 17, caractérisé en ce qu'il integre lesdits moyens de cryptage, ledit dispositif émetteur étant de type analogique.
20. Noeud d'entrée selon la revendication 16, caractérisé en ce que le flu;ç de données transmis par lesdits moyens de transmission est un flux de données en clair.
21. Noeud d'entrée selon la revendication 20, caractérisé en ce que ledit dispositif émetteur (007) est de type numérique et comprend des moyens de 20 cryptage dudit flux de données au moyen d'une première clé.
22. Noeud d'entrée selon la revendication 21, caractérisé en ce qu'il comprend en outre des seconds moyens d'authentification auprès du dispositif émetteur (007) de façon à obtenir la première clé et des moyens de décryptage dudit flux de données.
23. Noeud d'entrée selon l'une quelconque des revendications 16 à 22, caractérisé en ce que lesdits moyens d'indication coopèrent avec une information comprise dans un champ de contrôle transporté avec le flux de données.
24. Noeud d'entrée selon l'une quelconque des revendications 16 à 23 caractérisé en ce que les moyens d'authentification des noeuds de sorties comprennent: des moyens de détermination du nombre N1 de noeuds de sortie qui sont destinataires du flux de données; des moyens de détermination du nombre N2 de requêtes de transmission en clair reçues par le noeud d'entrée et émises par lesdits noeuds de sortie; des moyens de comparaison des nombres N1 et N2.
25. Noeud d'entrée selon la revendication 24 caractérisé en ce que lesdits moyens de détermination du nombre N2 comprennent des moyens de comptage du nombre de requêtes de transmission en clair réellement reçues à l'issue d'une temporisation d'une durée prédéterminée.
26. Noeud d'entrée selon l'une quelconque des revendications 16 à 25 caractérisé en ce que la requête de transmission en clair comprend au moins une information permettant de quantifier un niveau d'autorisation dudit dispositif récepteur pour l'accès audit flux de données.
27. Noeud d'entrée selon l'une quelconque des revendications 24 à 26 caractérisé en ce qu'il comprend des moyens de transmission aux autres noeuds d'une notification d'échec d'authentification, lesdits moyens étant activés si les noeuds de sorties ne sont pas authentifiés.
28. Noeud de sortie impliqué dans un transfert sécurisé d'un flux de données depuis un dispositif émetteur (007) vers au moins un dispositif récepteur (009), via un réseau (1001) comprenant une pluralité de noeuds reliés entre eux par une pluralité de liens, le dispositif émetteur étant connecté à un noeud d'entrée (003) dans le réseau, chaque dispositif récepteur étant connecté audit noeud de sortit; du réseau caractérisé en ce que ledit noeud de sortie comprend: - des moyens de réception du flux de données à partir du noeud d'entrée; - des moyens de réception d'une information indiquant que la réception ou le maintien de la réception du flux de données en clair nécessite l'authentification des noeuds de sortie; - des moyens de transmission d'une requête d'authentification audit noeud d'entrée.
FR0408740A 2004-08-06 2004-08-06 Procede de securisation du transfert d'un flux de donnees, produit programme d'ordinateur, moyen de stockage et noeuds correspondants Expired - Fee Related FR2874143B1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR0408740A FR2874143B1 (fr) 2004-08-06 2004-08-06 Procede de securisation du transfert d'un flux de donnees, produit programme d'ordinateur, moyen de stockage et noeuds correspondants
US11/190,105 US7797755B2 (en) 2004-08-06 2005-07-27 Method to secure the transfer of a data stream, corresponding computer program product, storage means and nodes
CN200510089371.2A CN1731719B (zh) 2004-08-06 2005-08-05 数据流传输的保密方法、程序产品、存储装置和节点
JP2005229994A JP4006454B2 (ja) 2004-08-06 2005-08-08 データ・ストリームの転送を保護する方法及び対応するコンピュータ・プログラム製品、記憶手段及びノード

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0408740A FR2874143B1 (fr) 2004-08-06 2004-08-06 Procede de securisation du transfert d'un flux de donnees, produit programme d'ordinateur, moyen de stockage et noeuds correspondants

Publications (2)

Publication Number Publication Date
FR2874143A1 true FR2874143A1 (fr) 2006-02-10
FR2874143B1 FR2874143B1 (fr) 2006-11-24

Family

ID=34952457

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0408740A Expired - Fee Related FR2874143B1 (fr) 2004-08-06 2004-08-06 Procede de securisation du transfert d'un flux de donnees, produit programme d'ordinateur, moyen de stockage et noeuds correspondants

Country Status (4)

Country Link
US (1) US7797755B2 (fr)
JP (1) JP4006454B2 (fr)
CN (1) CN1731719B (fr)
FR (1) FR2874143B1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2907287A1 (fr) * 2006-10-16 2008-04-18 Canon Kk Procedes de transmission securisee d'un contenu,incluant une restriction d'acces a ce contenu,produit programme d'ordinateur ,moyen de stockage,et dispositifs correspondants.
GB2586281A (en) * 2019-08-16 2021-02-17 Rescyou Ltd Pool safety device

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2880485B1 (fr) * 2005-01-06 2007-03-16 Canon Europa Nv Naamlooze Venn 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.
US8543724B2 (en) * 2010-04-30 2013-09-24 Digital Keystone, Inc. Methods and apparatuses for a projected PVR experience
US9928485B2 (en) 2011-09-07 2018-03-27 Elwha Llc Computational systems and methods for regulating information flow during interactions
US9491146B2 (en) * 2011-09-07 2016-11-08 Elwha Llc Computational systems and methods for encrypting data for anonymous storage
US10546295B2 (en) 2011-09-07 2020-01-28 Elwha Llc Computational systems and methods for regulating information flow during interactions
US9159055B2 (en) 2011-09-07 2015-10-13 Elwha Llc Computational systems and methods for identifying a communications partner
US9195848B2 (en) * 2011-09-07 2015-11-24 Elwha, Llc Computational systems and methods for anonymized storage of double-encrypted data
US10263936B2 (en) 2011-09-07 2019-04-16 Elwha Llc Computational systems and methods for identifying a communications partner
US9690853B2 (en) 2011-09-07 2017-06-27 Elwha Llc Computational systems and methods for regulating information flow during interactions
US9167099B2 (en) 2011-09-07 2015-10-20 Elwha Llc Computational systems and methods for identifying a communications partner
US9747561B2 (en) 2011-09-07 2017-08-29 Elwha Llc Computational systems and methods for linking users of devices
US10185814B2 (en) 2011-09-07 2019-01-22 Elwha Llc Computational systems and methods for verifying personal information during transactions
US9141977B2 (en) 2011-09-07 2015-09-22 Elwha Llc Computational systems and methods for disambiguating search terms corresponding to network members
US9432190B2 (en) * 2011-09-07 2016-08-30 Elwha Llc Computational systems and methods for double-encrypting data for subsequent anonymous storage
US10546306B2 (en) 2011-09-07 2020-01-28 Elwha Llc Computational systems and methods for regulating information flow during interactions
US8504834B2 (en) * 2011-12-30 2013-08-06 Sandisk Technologies Inc. Method and system for activation of local content with legacy streaming systems
US9596436B2 (en) 2012-07-12 2017-03-14 Elwha Llc Level-one encryption associated with individual privacy and public safety protection via double encrypted lock box
US10277867B2 (en) 2012-07-12 2019-04-30 Elwha Llc Pre-event repository associated with individual privacy and public safety protection via double encrypted lock box
US9042546B2 (en) * 2012-10-16 2015-05-26 Elwha Llc Level-two encryption associated with individual privacy and public safety protection via double encrypted lock box
US9521370B2 (en) 2012-07-12 2016-12-13 Elwha, Llc Level-two decryption associated with individual privacy and public safety protection via double encrypted lock box
US9825760B2 (en) 2012-07-12 2017-11-21 Elwha, Llc Level-two decryption associated with individual privacy and public safety protection via double encrypted lock box
US10210344B2 (en) * 2016-06-09 2019-02-19 JPS Engineering Corp. Systems and methods for cybersecurity
US20170357801A1 (en) * 2016-06-09 2017-12-14 JPS Engineering Corp. Isolation system for cybersecurity
CN110557198A (zh) * 2018-05-30 2019-12-10 富士通株式会社 光通信控制方法、装置和通信系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0887982A2 (fr) * 1997-06-23 1998-12-30 Sun Microsystems, Inc. Procédé et système de distribution sécurisée de clés cryptographiques dans un réseau à destinations multiples
WO2002096151A1 (fr) * 2001-05-22 2002-11-28 Flarion Technologies, Inc. Systeme d'authentification pour entites mobiles
US20040073786A1 (en) * 2002-10-15 2004-04-15 O'neill Alan Method and apparatus for providing authentication, authorization and accounting to roaming nodes

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3502200B2 (ja) * 1995-08-30 2004-03-02 株式会社日立製作所 暗号通信システム
CA2228687A1 (fr) * 1998-02-04 1999-08-04 Brett Howard Reseaux prives virtuels proteges
US7370351B1 (en) * 2001-03-22 2008-05-06 Novell, Inc. Cross domain authentication and security services using proxies for HTTP access
SE0101295D0 (sv) * 2001-04-10 2001-04-10 Ericsson Telefon Ab L M A method and network for delivering streaming data

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0887982A2 (fr) * 1997-06-23 1998-12-30 Sun Microsystems, Inc. Procédé et système de distribution sécurisée de clés cryptographiques dans un réseau à destinations multiples
WO2002096151A1 (fr) * 2001-05-22 2002-11-28 Flarion Technologies, Inc. Systeme d'authentification pour entites mobiles
US20040073786A1 (en) * 2002-10-15 2004-04-15 O'neill Alan Method and apparatus for providing authentication, authorization and accounting to roaming nodes

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MENEZES, VANSTONE, OORSCHOT: "Handbook of Applied Cryptography", 1997, CRC PRESS LLC, USA, XP002323806 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2907287A1 (fr) * 2006-10-16 2008-04-18 Canon Kk Procedes de transmission securisee d'un contenu,incluant une restriction d'acces a ce contenu,produit programme d'ordinateur ,moyen de stockage,et dispositifs correspondants.
GB2586281A (en) * 2019-08-16 2021-02-17 Rescyou Ltd Pool safety device

Also Published As

Publication number Publication date
US20060029228A1 (en) 2006-02-09
US7797755B2 (en) 2010-09-14
FR2874143B1 (fr) 2006-11-24
CN1731719A (zh) 2006-02-08
CN1731719B (zh) 2010-05-05
JP4006454B2 (ja) 2007-11-14
JP2006087079A (ja) 2006-03-30

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
EP1815681B1 (fr) Unité de traitement de données audio/vidéo numériques et méthode de contrôle d'accès audites données
US20060229992A1 (en) Securely relaying content using key chains
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
FR2835986A1 (fr) Systeme de transmission de signaux audiovisuels entre noeud(s) source et noeud(s) destinataire(s)
EP1765012A1 (fr) Méthode de vérification d'un dispositif cible relié à un dispositif maître
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.
EP1479233B1 (fr) Dispositif de traitement et procede de transmission de donnees chiffrees pour un premier domaine dans un reseau appartenant a un second domaine
US20070180231A1 (en) Preventing entitlement management message (EMM) filter attacks
EP1479234B1 (fr) Procede de traitement de donnees chiffrees pour un premier domaine et recues dans un reseau appartenant a un second domaine
EP1946524B1 (fr) Procede de detection de proximite ameliore
EP1419640B1 (fr) Reseau numerique local, procedes d'installation de nouveaux dispositifs et procedes de diffusion et de reception de donnees dans un tel reseau
Sakamoto et al. A digital HDTV receiver with home networking function and digital content storage
FR2877524A1 (fr) Procedes de stockage securise et de lecture securisee, produit programme d'ordinateur, moyen de stockage et systeme correspondants
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
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.
EP3228083B1 (fr) Procédé de gestion du droit d'accès a un contenu numérique
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
FR2826814A1 (fr) Procede d'utilisation a distance de moyens de reception de signaux audiovisuels appartenant a un reseau audiovisuel domestique primaire, passerelles, procede d'allocation de ressources correspondants
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
FR2906097A1 (fr) Procedes d'echange de donnees securises, produit programme d'ordinateur, moyen de stockage et dispositifs correspondants.
FR2828357A1 (fr) Procede de traitement de signaux de telecommande au sein d'un reseau audiovisuel domestique, signal, dispositifs et programme d'ordinateur correspondants
FR2953672A1 (fr) Procede de dechiffrement de donnees par un equipement utilisateur comportant un terminal et un module de securite
FR2826818A1 (fr) Procede de controle de la reproduction et/ou de la diffusion de signaux audiovisiuels transmis au sein d'un reseau audiovisuel domestique

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20140430