Brevet FR2969444A1 — publié le 20120622

Distribution sélective d'un flux multicast La présente invention concerne la distribution sélective de flux de données à destination d'utilisateurs d'un réseau de distribution de contenus. Il est possible de distribuer de façon sélective un contenu protégé après un contrôle effectué par un élément du réseau (routeur, DSLAM (« Digital Subscriber Line Access Multiplexer »), etc.) Le contrôle est effectué en préalable à la distribution du contenu par l'élément placé dans le réseau. Par exemple, le contrôle porte sur l'adéquation entre les conditions d'accès présentes dans le flux et les droits de l'utilisateur stockés dans une table de l'élément du réseau. L'envoi du flux est conditionné par l'adéquation d'informations extraites du signal par l'équipement réseau et les droits utilisateur stockés dans la mémoire de l'équipement. Il est alors nécessaire d'avoir une capacité de stockage dans l'équipement du réseau lui permettant de mémoriser les informations relatives aux droits des terminaux connectés. En outre, les traitements peuvent s'avérer complexes dans le cas du stockage local des autorisations. En effet, avant de procéder à la distribution du contenu, l'équipement du réseau doit être capable d'extraire les éléments pertinents du signal reçu afin de réaliser la comparaison avec les autorisations présentes. Selon un autre exemple, le contrôle est effectué par un élément du réseau et porte sur un ticket obtenu auprès d'un serveur gérant l'accès au service. Dans ce cas, l'élément du réseau et le serveur délivrant le ticket partagent une même base de données. Il est alors nécessaire d'établir un lien (ou le partage de données) entre le système d'informations (SI) commercial de l'opérateur gérant le service et les éléments du réseau en charge d'effectuer le contrôle des données commerciales associées aux contenus protégés (appartenance à une offre ou identifiant de l'offre, validité d'un ticket dans une base de données, etc.). En outre, ce mode opératoire crée un lien fort entre le SI commercial de l'opérateur du service et le réseau en charge de la distribution du contenu, alors qu'il est souvent plus recherché de séparer le réseau et les services. Dans les deux exemples précédents où l'opérateur de service n'est pas l'opérateur du réseau, le mécanisme proposé impose un partage d'informations et aussi la mise en place de passerelles entre les opérateurs. Selon un autre exemple encore, le contrôle de l'accès internet et des autorisations de service est effectué par le biais d'une requête transmise par le DSLAM (« Digital Subscriber Line Access Multiplexer ») en direction d'un serveur fonctionnant selon le protocole RADIUS (« Remote Authentication Dial-In User Service »). Dans cet exemple, il est nécessaire que l'autorisation soit effectuée par un serveur tiers (contrôle déporté). En outre, le contrôle nécessite l'adjonction d'un équipement externe (le serveur RADIUS). Dans tous les cas, que l'opérateur du service soit ou non l'opérateur du réseau, il faut créer des passerelles complexes et coûteuses (parce que inexistantes le plus souvent) entre les frontaux commerciaux et les équipements intervenant dans la distribution finale du contenu (DSLAM par exemple). L'invention propose des améliorations aux solutions existantes. A cet effet, selon un premier aspect de l'invention, il est proposé un procédé d'accès à un flux de données de contenu par un terminal de télécommunications dans un réseau télécommunications, comportant les étapes suivantes mises en oeuvre par le terminal: - envoi d'une première requête à destination d'une entité de gestion d'accès à un service, cette première requête visant à identifier le terminal auprès de l'entité de gestion d'accès au service, - après identification du terminal par l'entité de gestion d' accès à au service, réception de moyens d'authentification fournis par l'entité de gestion d'accès à au service, - envoi d'une deuxième requête à destination d'une entité d'accès , cette deuxième requête visant l'accès par le terminal au flux de données de contenu, et cette deuxième requête étant générée en utilisant les moyens d'authentification fournis par l'entité de gestion d'accès au service, et - réception en provenance de l'entité d'accès d'un flux de données de contenu, suite à une authentification positive du terminal auprès de l'entité d'accès. On peut ainsi réaliser la distribution sélective d'un flux, notamment d'un flux multicast, à des usagers dûment autorisés et identifiés sans qu'il soit nécessaire d'établir un lien régulier entre les équipements du réseau (DSLAM) de l'opérateur du réseau et le système d'informations commercial (abonnements) de l'opérateur du service. Ainsi, on réduit l'impact du contrôle effectué par l'équipement du réseau à la vérification d'une signature lors de la requête d'accès au flux effectuée par le terminal. Par ailleurs, le lien entre le SI commercial de l'opérateur du service et les équipements du réseau (voire avec un équipement externe) n'est plus nécessaire. Le contrôle peut être du type « stand alone ». Il est également possible de limiter la configuration des équipements du réseau en charge d'effectuer ce contrôle, à l'insertion d'une clé locale en préalable à l'ouverture du service. Ainsi, le traitement réalisé par ces équipements peut se limiter à la vérification d'une signature des paramètres transmis dans la requête du terminal demandeur. D'une manière générale on peut distribuer sélectivement un flux en maintenant une séparation service/réseau. Des modes de réalisation peuvent facilement s'insérer dans une architecture mono opérateur mais aussi, multi opérateurs. On offre également un complément à la sécurité de l'accès à un flux. Les contenus peuvent n'être distribués qu'aux usagers dûment identifiés comme étant clients du service. Des modes de réalisation peuvent s'appliquer aux distributions sélectives de contenus (IPTV), notamment sur réseau fibre (FTTH) ou cuivre (ADSL). Des modes de réalisation permettent d'offrir une nouvelle fonctionnalité dans un réseau déjà existant sans impacter lourdement la distribution de flux sélective. Des modes de réalisation peuvent comporter l'une ou plusieurs des mesures suivantes. L'entité de gestion d'accès au service détermine un ou plusieurs droits d'accès du terminal à un ou plusieurs flux de données. La première requête et/ou la deuxième requête comporte au moins l'un d'un identifiant du terminal et d'une adresse réseau du terminal. Les moyens d'authentification comportent une première clé cryptographique, par exemple pour signer la deuxième requête. L'entité d'accès obtient la première clé cryptographique et authentifie la deuxième requête en vérifiant la signature de la deuxième requête au moyen de la première clé cryptographique La première clé cryptographique est obtenue dynamiquement à partir d'au moins l'un d'un identifiant du terminal et d'une adresse réseau du terminal. Les moyens d'authentification comportent un certificat d'authentification autorisant l'accès par le terminal au flux de données. Le certificat comporte en outre une durée de validité du certificat. Le certificat comporte au moins un identifiant que l'entité d'accès peut vérifier (par exemple l'identifiant de ligne téléphonique, le numéro de port sur lequel la ligne téléphonique est raccordée à l'entité d'accès, ...). La deuxième requête comporte le certificat. L'entité d'accès vérifie le certificat au moyen d'une deuxième clé d'autorité de certification. La deuxième requête est signée par le terminal au moyen d'une troisième clé cryptographique. L'entité d'accès authentifie la deuxième requête en vérifiant la signature de la deuxième requête au moyen de la troisième clé cryptographique. Selon d'autres aspects de l'invention, il est prévu : - un programme d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé selon le premier aspect de l'invention lorsque le programme est exécuté par un processeur ; - un support lisible par un ordinateur sur lequel est enregistré un tel programme d'ordinateur ; - un terminal de télécommunications pour la mise en oeuvre d'un procédé selon le premier aspect de l'invention. Un tel terminal comporte : - une unité de communication configurée pour envoyer une première requête à destination d'une entité de gestion d'accès à un service, cette première requête visant à identifier le terminal auprès de l'entité de gestion d'accès à un service, pour recevoir des moyens d'authentification fournis par l'entité de gestion d'accès au service après identification du terminal par l'entité de gestion d'accès à un service, pour envoyer une deuxième requête à destination d'une entité d'accès, cette deuxième requête visant l'accès par le terminal au flux de données de contenu, et pour recevoir en provenance de l'entité d'accès d'un flux de données de contenu, suite à une authentification positive du terminal auprès de l'entité d'accès, et - une unité de traitement configurée pour générer la deuxième requête en utilisant les moyens d'authentification fournis par l'entité de gestion d'accès au service. Les avantages procurés par le programme d'ordinateur, le support lisible par ordinateur, et le terminal, tels que succinctement exposés ci-dessus, sont au moins identiques à ceux mentionnés plus haut en liaison avec le procédé selon le premier aspect. D'autres caractéristiques et avantages de l'invention apparaîtront encore à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés sur lesquels: - la figure 1 illustre un système général de mise en oeuvre de modes de réalisation de l'invention; - la figure 2 est un organigramme général représentant des étapes mises en oeuvre selon un premier mode de réalisation; - la figure 3 est un organigramme général représentant des étapes mises en oeuvre selon un deuxième mode de réalisation ; - la figure 4 est un organigramme général représentant des étapes mises en oeuvre selon un troisième mode de réalisation ; et - la figure 5 illustre schématiquement la structure d'éléments compris dans un système de ces modes de réalisation de l'invention. La figure 1 illustre un système général de mise en oeuvre de différents modes de réalisation de l'invention, selon un exemple particulier de réalisation. Ce système comprend: - une entité GAS de gestion d'accès à un service 11 gérant ici l'accès de terminaux 10 à un service TV de transmission de programmes audiovisuels, fourni par un opérateur et éventuellement organisé en bouquets de chaînes TV, - une base de données utilisateurs 12, connectée à l'entité GAS 11 de gestion d'accès au service et stockant des informations relatives à des utilisateurs du service TV fournies par l'opérateur de service, ces informations comprenant notamment des droits d'abonnement d'utilisateurs à des programmes audiovisuels éventuellement organisés en bouquets de chaînes TV, - une entité d'accès à des flux de données de programmes audiovisuels, en l'espèce un DSLAM 13, - une base de données 15 connectée à l'entité d'accès 13, et - un terminal d'utilisateur 10, par exemple une « set top box », autrement dit un récepteur décodeur TV. Bien entendu, l'entité de gestion de service 11 pourrait fournir un service autre que la transmission de programmes TV. La base de données 15 contient un ensemble de couples comprenant, chacun, une clé cryptographique Ki et un ensemble comprenant un ou plusieurs flux de données de programme audiovisuel. Ces couples sont fournis par l'opérateur gérant le service TV. Les programmes TV sont transmis sous la forme de flux de données à travers un réseau 14. L'entité d'accès 13, l'entité de gestion d'accès au service 11 et le terminal 10 sont connectés au réseau 14. Le procédé d'accès par le terminal à un flux de données d'un programme audiovisuel transmis via le réseau va maintenant être décrit d'une manière générale. Le terminal 10 envoie une requête vers l'entité de gestion d'accès au service 11, pour accéder au flux de données. L'entité GAS 11 de gestion d'accès au service se charge de déterminer si le terminal 10 a les droits d'accès nécessaires pour accéder au flux. Par exemple, elle vérifie les droits d'abonnement du terminal. A cet effet, l'entité GAS 11 peut consulter la base de données 12 comportant les informations dont elle a besoin. On fait ici l'hypothèse que le terminal 10 a les droits suffisants pour accéder au flux demandé. Lorsque l'entité de gestion d'accès au service 11 a vérifié que le terminal 10 peut accéder au flux, elle lui fournit des moyens d'authentification destinés à être utilisés par la suite pour accéder au flux souhaité. Après réception des moyens d'authentification, le terminal 10 accède au réseau 14 via l'entité d'accès, par exemple un DSLAM 13, en utilisant les moyens d'authentification qui lui ont été fournis par l'entité 11 de gestion d'accès au service. Le DSLAM 13 authentifie le terminal 10 et autorise ou non l'accès au flux demandé, selon que l'authentification est valide ou invalide. Pour authentifier le terminal 10, le DSLAM 13 peut consulter une base de données 15 comportant les informations dont il a besoin. En cas d'authentification valide, le DSLAM 13 transmet le flux de données demandé au terminal 10. Dans la suite, on décrit trois modes distincts de réalisation particuliers du procédé d'accès à un flux de données par le terminal 10, selon l'invention. Le premier mode de réalisation est décrit en référence à la figure 2. Le terminal 10 envoie une requête Regl vers l'entité 11 de gestion d'accès au service (GAS) 11 lors de l'étape S200. Cette requête Regl lui permet de s'identifier auprès de l'entité de gestion d'accès au service 11 et, comme on le voit dans la suite, d'obtenir des moyens d'authentification pour recevoir le flux transmis par le réseau 14. La requête Regl comporte des informations d'identification du terminal 10 (et/ou de l'utilisateur), par exemple un identifiant du terminal (ou de l'utilisateur), et une adresse IP du terminal. L'entité 11 de gestion d'accès au service (GAS) reçoit la requête Regl. Elle détermine ensuite lors de l'étape S201, l'identité de l'utilisateur soit à partir de l'identifiant du terminal soit à partir de l'adresse IP du terminal. Lors de cette même étape 5201, l'entité de gestion d'accès au service 11 détermine à partir de l'identité de l'utilisateur les droits de l'utilisateur sur les différents flux disponibles sur le réseau. Par exemple, l'entité de gestion d'accès au service 11 consulte une table, stockée dans la base de données 12, de correspondance entre des informations d'identification d'utilisateur et/ou de terminal et un ensemble d'identifiants de flux{Flux.Id} autorisés auquel ce terminal 10 peut accéder. L'entité de gestion d'accès au service 11 récupère alors une (ou plusieurs) clé cryptographique Kl auprès de la base de données 15 pour l'ensemble des flux {Flux.ld} autorisés pour l'utilisateur et la (ou les) transmet à l'utilisateur lors de l'étape S202. Lorsque l'utilisateur souhaite accéder à une chaîne particulière, autrement dit à un flux de données audio/vidéo particulier, le terminal 10 émet, lors de l'étape S204, une requête Req2 au DSLAM 13 pour obtenir le flux audio/vidéo souhaité. La requête Req2 est signée par la clé K1 qui est associée au flux demandé. La signature de la requête Req2 est réalisée lors de l'étape S203. La requête Req2 comporte par exemple l'adresse IP du terminal, l'adresse IP du flux demandé, et la signature de la requête. Le DSLAM 13 est configuré par l'opérateur du réseau 14 avec les clés associées aux flux. Il utilise la clé K1 en fonction de l'adresse IP du flux demandé (Flux IP). Par exemple, le DSLAM 13 obtient la clé dans la base de données 15 (qui peut être en fait la même base de données 12), lors de l'étape S205. Le DSLAM vérifie la signature de la requête Req2 à l'aide de cette clé lors de l'étape S206. Selon certaines alternatives, la clé à utiliser pour générer la signature de la requête Req2 est une clé obtenue dynamiquement à partir de l'adresse IP du terminal. Selon d'autres alternatives, elle est obtenue à partir d'un identifiant du terminal et de la clé Kl. Dans ce cas, du terminal 10 et le DSLAM 13 réalisent séparément une même opération de calcul afin de déterminer la clé à utiliser. Lorsque les vérifications sont effectuées, le DSLAM envoie une réponse au terminal 10 lors l'étape S207. Cette réponse peut comporter une indication d'acceptation de l'accès au flux, ou d'un refus d'accès au flux, selon que les vérifications effectuées ont réussi ou échoué. Lorsque les vérifications ont réussi, le flux est transmis par le DSALM 13 au terminal 10 lors de l'étape S208. Un deuxième mode de réalisation particulier est décrit en référence à la figure 3. Comme dans le premier mode de réalisation, une requête d'authentification Regl permettant de s'identifier auprès de l'entité GAS de gestion d'accès au service 11 est envoyée par le terminal 10 vers l'entité de gestion d'accès au service 11 lors de l'étape S200, et l'entité de gestion d'accès au service 11 effectue des vérifications lors de l'étape S201. Dans ce deuxième mode de réalisation particulier, à la place d'une clé cryptographique, l'entité de gestion d'accès au service 11 génère un certificat électronique d'authentification Cert lors d'une étape S302, et transmet ce certificat lors de l'étape S303 au terminal 10. Par exemple, le certificat électronique d'authentification Cert contient les droits de l'utilisateur sur un ensemble de flux identifiés par un identifiant de flux « flux.ID » ou par une adresse IP de flux « Flux.IP » ou bien les deux) et une durée de validité. Le certificat électronique Cert est signé par l'entité de gestion d'accès au service 11. Lorsque l'utilisateur du terminal 10 souhaite regarder une chaîne particulière, autrement dit accéder à un flux de données particulier, le terminal 10 émet, lors de l'étape S304, la requête Req2 vers le DSLAM 13 pour obtenir le flux audio/vidéo. Dans ce mode de réalisation, la requête Req2 est une requête non signée mais le terminal 10 y insère le certificat obtenu auprès de l'entité GAS de gestion d'accès au service 11. Le DSLAM 13 vérifie, lors de l'étape S305, le certificat Cert et sa validité et vérifie que le flux demandé (soit avec Flux.ID soit avec Flux.IP) fait bien partie des flux autorisés dans le certificat Cert. L'entité GAS de gestion d'accès au service 11 peut ajouter dans le certificat Cert soit un identifiant de la ligne téléphonique soit un numéro de port sur lequel la ligne téléphonique est raccordée au DSLAM. Cela permet en plus au DSLAM de contrôler de façon "physique' la provenance de la requête Req2. Ensuite, le processus se poursuit avec les étapes S207 et S208 évoquées ci-avant pour le premier mode de réalisation. Un troisième mode de réalisation particulier est décrit en référence à la figure 4. Comme dans le premier mode de réalisation, la requête Regl est envoyée par le terminal 10 vers l'entité GAS de gestion d'accès au service 11 lors de l'étape S200, et l'entité GAS de gestion d'accès au service 11 effectue des vérifications lors de l'étape S201. Ensuite, l'entité de gestion d'accès au service 11 récupère une clé publique associée au terminal soit en interrogeant la base de données 12, soit par extraction de la requête Regl dans le cas où le terminal a inséré la clé publique dans la requête Regl. L'entité de gestion d'accès au service 11 génère ensuite un certificat Cert pour la clé publique du terminal 10, comme décrit ci-avant pour le deuxième mode de réalisation. Lorsque l'utilisateur du terminal 10 souhaite regarder une chaîne particulière (un flux particulier), le terminal 10 émet la requête Req2 au DSLAM 13 pour obtenir le flux audio/vidéo. La requête Req2 est signée par le terminal 10 lors l'étape S404 en utilisant la clé privée du terminal. Le certificat Cert est également envoyé dans la requête Req2. Le DSLAM 13 vérifie alors: - le certificat Cert et sa validité (étape S305), - que la signature de la requête Req2 (la clé publique pour vérifier Sign2 est incluse dans Cert) est correcte (étape S206), et - que l'adresse IP du flux @Flux.IP (ou bien l'identifiant du flux « Flux.ID ») est une des adresses IP (ou bien un des flux) autorisé(e)s dans le certificat. L'entité de gestion d'accès au service 11 peut ajouter dans le certificat Cert soit un identifiant de la ligne téléphonique soit un numéro de port sur lequel la ligne téléphonique est raccordé au DSLAM. Cela permet en plus au DSLAM 13 de contrôler de façon "physique' la provenance de la requête Req2. Ensuite le processus se poursuit avec les étapes S207 et S208 évoquées ci-avant pour le premier mode de réalisation. Un programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé selon l'invention peut être réalisé par la personne du métier selon un algorithme général déduit des diagrammes des figures 2 à 4, et de la présente description détaillée. La figure 5 illustre schématiquement la structure des éléments compris dans le système de la figure 1. Chaque dispositif (le terminal, l'entité de gestion de service ou l'entité d'accès) comporte une unité de traitement 50 configurée pour mettre en oeuvre les étapes correspondantes du procédé, par exemple en mettant en oeuvre un programme d'ordinateur selon un mode de réalisation de l'invention. Chaque dispositif comporte en outre une unité de mémoire 51 pour stocker des données de calcul ou pour le stockage d'un programme d'ordinateur selon la présente invention pour son exécution par un processeur de l'unité de traitement. Chaque dispositif comporte en outre une unité de communication 52 pour communiquer notamment avec les autres dispositifs du système ou avec les bases données 12 et 15 selon l'invention. La présente invention ne se limite pas aux formes de réalisation présentées. D'autres variantes et 5 modes de réalisation peuvent être déduits et mis en oeuvre par la personne du métier à la lecture de la présente description et des figures annexées. REVENDICATIONS1. Procédé d'accès à un flux de données de contenu par un terminal de télécommunications (10) dans un réseau télécommunications (14), comportant les étapes suivantes, mises en oeuvre par le terminal: - envoi (S200) d'une première requête (Regl) à destination d'une entité de gestion d'accès à un service (11), cette première requête visant à identifier le terminal auprès de l'entité de gestion d'accès au service, - après identification du terminal par l'entité de gestion d'accès à au service (11), réception (S202, S303) de moyens d'authentification (Kl, Cert) fournis par l'entité de gestion d'accès au service (11), - envoi (S204, S304, S405) d'une deuxième requête (Req2) à destination d'une entité d'accès (13), cette deuxième requête visant l'accès par le terminal au flux de données de contenu, et cette deuxième requête étant générée en utilisant les moyens d'authentification fournis par l'entité de gestion d'accès au service, et - réception en provenance de l'entité d'accès d'un flux de données de contenu, suite à une authentification positive du terminal auprès de l'entité d'accès. 2. Procédé selon la revendication 1, comportant en outre une étape de détermination (S201) d'un ou plusieurs droits d'accès du terminal à un ou plusieurs flux de données par l'entité de gestion d'accès au service. 3. Procédé selon la revendication 1, dans lequel la première requête et/ou la deuxième requête comporte au moins l'un d'un identifiant du terminal et d'une adresse réseau du terminal. 4. Procédé selon la revendication 1, dans lequel les moyens d'authentification comportent une première clé cryptographique pour signer la deuxième requête. 5. Procédé selon la revendication 4, dans lequel l'entité d'accès authentifie la deuxième requête en 25 vérifiant la signature de la deuxième requête au moyen de la première clé cryptographique. 6. Procédé selon l'une des revendications 4 et 5, dans lequel la première clé cryptographique est obtenue dynamiquement à partir d'au moins l'un d'un identifiant du terminal et d'une adresse réseau du terminal. 30 7. Procédé selon la revendication 1, dans lequel les moyens d'authentification comportent un certificat d'authentification autorisant l'accès par le terminal au flux de données.20 8. Procédé selon la revendication 7, dans lequel le certificat comporte en outre une durée de validité du certificat. 9. Procédé selon la revendication 7 ou 8, dans lequel le certificat comporte au moins l'un d'un identifiant de ligne téléphonique et d'un numéro de port sur lequel la ligne téléphonique est raccordée à l'entité d'accès. 10. Procédé selon l'une des revendications 7 à 9, dans lequel la deuxième requête comporte le certificat. 11. Procédé selon l'une des revendications 7 à 10, dans lequel l'entité d'accès vérifie le certificat au moyen d'une deuxième clé d'autorité de certification. 12. Procédé selon l'une des revendications 7 à 11, dans lequel la deuxième requête est signée par le 15 terminal au moyen d'une troisième clé cryptographique. 13. Procédé selon la revendication 12, dans lequel l'entité d'accès authentifie la deuxième requête en vérifiant la signature de la deuxième requête au moyen de la troisième clé cryptographique 20 14. Programme d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé selon l'une des revendications précédentes, lorsqu'il est exécuté par un processeur. 15. Terminal de télécommunications (10) configuré pour accéder à un flux de données de contenu dans un réseau de télécommunications (14), comportant : 25 - une unité de communication (42) configurée pour envoyer une première requête (Regl) à destination d'une entité de gestion d'accès à un service (11), cette première requête visant à identifier le terminal auprès de l'entité de gestion d'accès à un service, pour recevoir des moyens d'authentification (Kl, Cert) fournis par l'entité de gestion d'accès au service (11) après identification du terminal par l'entité de gestion d'accès à un service (11), pour envoyer une deuxième requête (Req2) à destination d'une entité d'accès 30 (13), cette deuxième requête visant l'accès par le terminal au flux de données de contenu, et pour recevoir en provenance de l'entité d'accès d'un flux de données de contenu, suite à une authentification positive du terminal auprès de l'entité d'accès, et10- une unité de traitement (40) configurée pour générer la deuxième requête en utilisant les moyens d'authentification fournis par l'entité de gestion d'accès au service.