FR3110263A1 - Procédé et système pour authentifier une application informatique, ou une fonction de l’application, exécutée par un récepteur multimédia - Google Patents
Procédé et système pour authentifier une application informatique, ou une fonction de l’application, exécutée par un récepteur multimédia Download PDFInfo
- Publication number
- FR3110263A1 FR3110263A1 FR2004857A FR2004857A FR3110263A1 FR 3110263 A1 FR3110263 A1 FR 3110263A1 FR 2004857 A FR2004857 A FR 2004857A FR 2004857 A FR2004857 A FR 2004857A FR 3110263 A1 FR3110263 A1 FR 3110263A1
- Authority
- FR
- France
- Prior art keywords
- receiver
- multimedia
- access module
- application
- data
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 75
- 238000004883 computer application Methods 0.000 title claims abstract description 17
- 230000005540 biological transmission Effects 0.000 claims abstract description 28
- 230000006870 function Effects 0.000 claims description 31
- 238000012545 processing Methods 0.000 claims description 22
- 238000012546 transfer Methods 0.000 claims description 15
- 238000004590 computer program Methods 0.000 claims description 5
- 230000000977 initiatory effect Effects 0.000 claims description 3
- 238000012795 verification Methods 0.000 claims description 3
- 238000005516 engineering process Methods 0.000 description 5
- 238000013475 authorization Methods 0.000 description 4
- 238000004891 communication Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 230000001419 dependent effect Effects 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 238000011144 upstream manufacturing Methods 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000005352 clarification Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000011065 in-situ storage Methods 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/44—Program or device authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
- G06F21/106—Enforcing content protection by specific content processing
- G06F21/1063—Personalisation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
- H04N21/25808—Management of client data
- H04N21/25816—Management of client data involving client authentication
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Multimedia (AREA)
- Technology Law (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
L’invention concerne un procédé pour authentifier une application informatique, ou une fonction de ladite application, exécutée par un récepteur multimédia, ledit procédé comprenant les étapes suivantes :- connecter un module d’accès au récepteur multimédia, lequel module d’accès est adapté pour vérifier des droits d’accès à un flux multimédia à accès contrôlé réceptionné dans ledit récepteur numérique,- enregistrer des données d’application dans le module d’accès,- transmettre de manière sécurisée, depuis le module d’accès et vers le récepteur multimédia, les données d’application,- installer, dans le récepteur multimédia, les données d'application sous la forme de l’application,- l’exécution de l’application, ou d’une fonction de ladite application, dans le récepteur multimédia, entraîne une transmission sécurisée, depuis ledit récepteur et vers le module d’accès, d’au moins une donnée d’authentification identifiable par ledit module d’accès,- authentifier l’application exécutée par le récepteur multimédia, laquelle authentification est basée sur l’identification, dans le module d’accès, de la donnée d’authentification transmise par ledit récepteur multimédia.
Description
Domaine technique.
L’invention concerne un procédé et un système pour authentifier une application informatique, ou l’une de ses fonctions, exécutée par un récepteur multimédia.
Le domaine de l’invention concerne les méthodes d’authentification d’une application informatique, ou l’une de ses fonctions, exécutée par un récepteur multimédia, et plus particulièrement l’authentification d’un marquage de vidéo, également connues par le terme de tatouage numérique (ou en anglais « watermarking ») et s’applique particulièrement, mais non exclusivement dans le domaine de la HbbTV (pour l’acronyme anglais « Hybrid Broadcast Broadband TV »).
État de la technique.
Le watermaking est avantageusement utilisé pour ajouter des informations cachées (ou marques) dans des vidéos dont l’accès est contrôlé telles que par exemple des programmes de chaînes de télévision payantes ou des vidéos à la demande (VOD). La marque peut comporter une identification du client final ou d’un équipement de lecture, l'identification de la chaîne qui émet le programme marqué, la date et l'heure de diffusion, etc. La marque peut être visible ou invisible de sorte qu’elle ne dégrade pas le contenu visuel affiché sur un écran. Elle permet de détecter des utilisations, des distributions ou des copies non autorisées des vidéos.
HbbTV permet la diffusion de chaînes de télévision et un accès internet à travers des récepteurs multimédias connectés et des décodeurs (en anglais « Set top boxes »). Les applications HbbTV permettent notamment de publier, en plus et en accompagnement de contenus multimédia, des contenus additionnels (textes, graphiques, liens internet, publicités, jeux, etc).
Dans un contexte de HbbTV, un récepteur multimédia est connecté à un réseau de diffusion unidirectionnel et à un réseau de diffusion bidirectionnel. Le réseau de diffusion unidirectionnel peut être un réseau DVB (Digital Video Broadcasting), par exemple DVB-T (système de diffusion terrestre), DVB-S (système de diffusion satellite) ou DVB-C (système de diffusion par câbles). Par le biais du réseau de diffusion unidirectionnel, le récepteur multimédia peut recevoir un flux multimédia comprenant notamment une vidéo (définie ici par un contenu audio/vidéo). Le réseau de diffusion bidirectionnel est par exemple un réseau internet pourvu d'un canal de retour, de sorte que le récepteur multimédia peut également recevoir de la vidéo par ce canal.
Lorsque le flux multimédia diffusé est à accès contrôlé, il est crypté (ou embrouillé) avant d'être diffusé. Un utilisateur final autorisé dispose d’une clé de décryptage, ou habilitation, permettant de décrypter le flux multimédia. Ce contrôle des droits d’accès est habituellement réalisé dans un module d’accès (par exemple un module d’accès conditionnel CAM DVB-CI+) connecté au récepteur multimédia.
À ce jour, il existe principalement deux technologies permettant d’appliquer un watermarking à une vidéo contenue dans un flux multimédia à accès contrôlé : dans le domaine de flux multimédia non compressé ou watermaking à une étape ; et dans le domaine de flux multimédia compressé ou watermaking à deux étapes.
Pour les flux multimédias non compressés, le récepteur numérique est en charge d’appliquer le watermarking en ajoutant au contenu vidéo un calque graphique contenant la marque ou en modifiant le plan vidéo.
Pour les flux multimédias compressés, le flux multimédia est généralement préparé en amont par l’opérateur en charge de la diffusion.
Selon un mode de réalisation, au moins deux variantes de la marque sont incluses dans le flux. Selon un processus de sélection dépendant de l’identifiant du récepteur multimédia, celui-ci réalise le watermaking en appliquant successivement l’une ou l’autre des variantes.
Selon un autre mode de réalisation, un processus de traitement dépendant d’un identifiant du module d’accès et de métadonnées (telles que des données de configuration), permet de rendre le flux unique en sortie du module d’accès.
Selon un mode de réalisation, au moins deux variantes de la marque sont incluses dans le flux. Selon un processus de sélection dépendant de l’identifiant du récepteur multimédia, celui-ci réalise le watermaking en appliquant successivement l’une ou l’autre des variantes.
Selon un autre mode de réalisation, un processus de traitement dépendant d’un identifiant du module d’accès et de métadonnées (telles que des données de configuration), permet de rendre le flux unique en sortie du module d’accès.
Les technologies de watermaking appliquées aux flux multimédias compressés présentent quelques inconvénients par rapport à celles appliquées aux flux multimédias non compressés. Elles nécessitent en effet de modifier les ressources informatiques du système de diffusion, notamment l’encodeur. Elles nécessitent en outre d’augmenter le débit de données (bitrate) dans le réseau de diffusion, l’ajout des différentes variantes de la marque augmentant d’environ 5% ce débit. Elles sont enfin moins robustes aux attaques, notamment les attaques de collisions.
Les modules d’accès, notamment les modules CAM utilisant la technologie DVB-CI+ (pour l’acronyme anglais « Common Interface Plus) pourraient être adaptés pour mettre en œuvre du watermaking sur des flux multimédia compressés. Mais en considérant les inconvénients précités, cette technologie n’est pas déployée actuellement.
Il peut toutefois être avantageux de mettre en œuvre du watermaking sur des flux multimédias non compressés, en utilisant un module d’accès, notamment avec un module CAM utilisant la technologie DVB-CI+ dans un contexte de HbbTV. En effet, pour des raisons de sécurité et en l’absence de processus d’authentification prévu par les normes actuellement en vigueur, les applications de HbbTV enregistrées dans les récepteurs multimédias peuvent difficilement assurer un watermaking sécurisé.
L’utilisation d’un module d’accès pour mettre en œuvre du watermaking n’est pas sans poser des difficultés techniques. En particulier, il est nécessaire d’accéder au contenu décodé du flux multimédia pour insérer la marque dans la vidéo. Considérant notamment les ressources informatiques limitées généralement embarquées dans un module d’accès, la mise en œuvre des opérations de décodage, de marquage et de réencodage dans ledit module peuvent paraître délicates. En pratique, il conviendrait d’augmenter les ressources informatiques (et donc le prix) du module d’accès, et d’augmenter le débit de données dans la connexion entre ledit module et le récepteur multimédia.
Plus généralement, l’authentification d’une application informatique (par exemple une application de HbbTV) ou d’une fonction de cette application (par exemple une application de watermaking), enregistrée dans un récepteur multimédia, au moyen d’un module d’accès paraît relativement complexe sauf à modifier substantiellement les ressources embarquées dudit module d’accès.
L’invention vise à remédier à cet état des choses. En particulier, un objectif de l’invention est de proposer une technique permettant d’utiliser un module d’accès pour authentifier une application informatique ou une fonction d’application informatique, enregistrée dans un récepteur multimédia, sans qu’il soit nécessaire de rajouter des ressources informatiques conséquentes dans le module d’accès et/ou sans engendrer d’augmentation sensible du débit de données entre ledit module et le récepteur multimédia.
Présentation de l’invention.
La solution proposée par l’invention est un procédé pour authentifier une application informatique, ou une fonction de ladite application, exécutée par un récepteur multimédia, ledit procédé comprenant les étapes suivantes :
- connecter un module d’accès au récepteur multimédia, lequel module d’accès est adapté pour vérifier des droits d’accès à un flux multimédia à accès contrôlé réceptionné dans ledit récepteur numérique,
- enregistrer des données d’application dans le module d’accès,
- transmettre de manière sécurisée, depuis le module d’accès et vers le récepteur multimédia, les données d’application,
- installer, dans le récepteur multimédia, les données d'application sous la forme de l’application,
- l’exécution de l’application, ou d’une fonction de ladite application, dans le récepteur multimédia, entraîne une transmission sécurisée, depuis ledit récepteur et vers le module d’accès, d’au moins une donnée d’authentification identifiable par ledit module d’accès,
- authentifier l’application exécutée par le récepteur multimédia, laquelle authentification est basée sur l’identification, dans le module d’accès, de la donnée d’authentification transmise par ledit récepteur multimédia.
- connecter un module d’accès au récepteur multimédia, lequel module d’accès est adapté pour vérifier des droits d’accès à un flux multimédia à accès contrôlé réceptionné dans ledit récepteur numérique,
- enregistrer des données d’application dans le module d’accès,
- transmettre de manière sécurisée, depuis le module d’accès et vers le récepteur multimédia, les données d’application,
- installer, dans le récepteur multimédia, les données d'application sous la forme de l’application,
- l’exécution de l’application, ou d’une fonction de ladite application, dans le récepteur multimédia, entraîne une transmission sécurisée, depuis ledit récepteur et vers le module d’accès, d’au moins une donnée d’authentification identifiable par ledit module d’accès,
- authentifier l’application exécutée par le récepteur multimédia, laquelle authentification est basée sur l’identification, dans le module d’accès, de la donnée d’authentification transmise par ledit récepteur multimédia.
Les données d’application (par exemple des données d’application de HbbTV et/ou des données d’application intégrant des données de marquage - la marque du watermaking) ne sont pas diffusées avec le flux multimédia. Un attaquant ne peut donc pas connaitre ces données s’il intercepte le flux multimédia en amont du récepteur multimédia. En outre, les données étant transmises de manière sécurisée (notamment au moyen d’une connexion sécurisée selon la norme DVB-CI+) entre le module d’accès et le récepteur multimédia, un attaquant ne peut pas non plus intercepter ces données entre ces deux éléments. On assure ainsi une sécurité optimale du procédé.
De plus, les données d’application transmises par le module d’accès se présentent habituellement sous la forme d’un ou plusieurs fichiers de données peu volumineux. Ces données peuvent être enregistrées dans une zone de mémoire native du module d’accès de sorte qu’il n’est pas nécessaire de rajouter des ressources informatiques à celui-ci. Ces données peu volumineuses ne nécessitent pas de modifier le débit de la connexion ni la bande-passante, entre le module d’accès et le récepteur multimédia.
Le watermaking est également sécurisé dans la mesure où les données d’application permettant d’exécuter la fonction de marquage proviennent du module d’accès. On limite ainsi les risques que le watermaking soit réalisé par une fonction de marquage fictive ou piratée ou par un récepteur multimédia piraté. Plus généralement, on limite les risques que l’application (ou l’une de ses fonctions) soit fictive ou piratée, ou exécutée par un récepteur multimédia piraté.
En outre, l’échange de données d’authentification permet de créer un lien de confiance entre le module d’accès et le récepteur multimédia. Le module d’accès est ainsi assuré que l’application informatique est effectivement exécutée par le bon récepteur multimédia.
D’autres caractéristiques avantageuses de l’invention sont listées ci-dessous. Chacune de ces caractéristiques peut être considérée seule ou en combinaison avec les caractéristiques remarquables définies ci-dessus, et faire l’objet, le cas échéant, d’une ou plusieurs demandes de brevet divisionnaires :
- Selon un mode de réalisation, le procédé comprend les étapes suivantes : - associer aux données d’application transmises au récepteur multimédia, plusieurs données d’authentification connues du module d’accès, laquelle association est réalisée dans ledit module ; - l’exécution de l’application, ou d’une fonction de ladite application, dans le récepteur multimédia, entraîne la transmission sécurisée, depuis ledit récepteur et vers le module d’accès, d’au moins une desdites données d’authentification ; - l’authentification de l’application est basée sur une comparaison, dans le module d’accès, de la donnée d’authentification transmise par le récepteur multimédia, aux données d’authentification connues dudit module.
- Selon un mode de réalisation, le procédé comprend les étapes suivantes : - horodater, dans le module d’accès, les données d’authentification destinées à être transmises au récepteur multimédia de manière à ce que lesdites données aient une période de validité limitée dans le temps ; - vérifier, dans le module d’accès, la période de validité de la donnée d’authentification transmise par le récepteur multimédia.
- Selon un mode de réalisation, le procédé comprend les étapes suivantes : - associer aux données d’application transmises au récepteur multimédia, une graine aléatoire adaptée pour initier un générateur de nombres pseudo-aléatoires installé dans ledit récepteur, lequel générateur est basé sur un algorithme connu du module d’accès, laquelle association est réalisée dans ledit module d’accès ; - l’exécution de l’application, ou d’une fonction de ladite application, dans le récepteur multimédia, entraîne la transmission sécurisée, depuis ledit récepteur et vers le module d’accès, d’au moins un nombre pseudo-aléatoire généré par le générateur de nombres pseudo-aléatoires ; - l’authentification de l’application est basée sur une comparaison, dans le module d’accès, du nombre pseudo-aléatoire transmis par le récepteur multimédia, à l’algorithme connu dudit module.
- Selon un mode de réalisation, le procédé comprend les étapes suivantes : - crypter le flux multimédia avant de le diffuser dans un réseau de diffusion ; - traiter le flux multimédia crypté dans le module d’accès, lequel traitement consiste à : -- décrypter le flux multimédia en fonction de droits d’accès enregistrés dans le module d’accès ; -- ajouter dans le flux multimédia décrypté, les données d’application ; -- chiffrer le flux multimédia contenant les données d’application ; - transmettre au travers de la connexion sécurisée, depuis le module d’accès et vers le récepteur multimédia, le flux multimédia traité ; - déchiffrer le flux multimédia traité dans le récepteur multimédia.
- Selon un mode de réalisation, le procédé comprend les étapes consistant à continuer à traiter le flux multimédia dans le module d’accès et/ou continuer à transférer le flux multimédia traité vers le récepteur multimédia, à la condition que la comparaison donne une correspondance entre la donnée d’authentification transmise par ledit récepteur et les données d’authentification connues dudit module.
- Selon un mode de réalisation, le procédé comprend les étapes consistant à continuer à traiter le flux multimédia dans le module d’accès et/ou continuer à transférer le flux multimédia traité vers le récepteur multimédia, à la condition que la période de validité de la donnée d’authentification transmise depuis ledit récepteur ne soit pas échue.
- Selon un mode de réalisation, le procédé comprend les étapes consistant à continuer à traiter le flux multimédia dans le module d’accès et/ou continuer à transférer le flux multimédia traité vers le récepteur multimédia, à la condition que la comparaison donne une correspondance entre le nombre pseudo-aléatoire transmis par ledit récepteur et l’algorithme connu dudit module.
- Selon un mode de réalisation, le procédé comprend les étapes suivantes : - crypter le flux multimédia avant de le diffuser dans un réseau de diffusion ; - réceptionner, par le récepteur multimédia, le flux multimédia crypté ; - après vérification des droits d’accès par le module d’accès, transmettre de manière sécurisée, depuis ledit module d’accès et vers le récepteur multimédia, une ou plusieurs clés de décryptage du flux multimédia crypté ; - décrypter, dans le récepteur multimédia, le flux multimédia avec la ou les clés de décryptage.
- Selon un mode de réalisation, le procédé comprend les étapes consistant à cesser de transmettre la ou les clés de décryptage au récepteur multimédia, si la comparaison ne donne pas une correspondance entre la donnée d’authentification transmise par ledit récepteur et les données d’authentification connues du module d’accès.
- Selon un mode de réalisation, le procédé comprend les étapes consistant à cesser de transmettre la ou les clés de décryptage au récepteur multimédia, si la période de validité de la donnée d’authentification transmise depuis ledit récepteur est échue.
- Selon un mode de réalisation, le procédé comprend les étapes consistant à cesser de transmettre la ou les clés de décryptage au récepteur multimédia, si la comparaison ne donne pas une correspondance entre le nombre pseudo-aléatoire transmis par ledit récepteur et l’algorithme connu du module d’accès.
- Selon un mode de réalisation, les données d’application sont adaptées pour être installées dans le récepteur multimédia sous la forme d’une application HbbTV.
- Selon un mode de réalisation, le procédé comprend les étapes le flux multimédia contient une vidéo et les données d’application intègre une fonction de marquage de vidéo, ledit procédé comprenant les étapes consistant à : - inclure des données de marquage de la vidéo dans les données d’application transmises au récepteur multimédia ; - réaliser le marquage de la vidéo en fonction des données de marquage, au moyen de la fonction de marquage de l’application exécutée dans le récepteur multimédia ; - le marquage de la vidéo dans le récepteur multimédia, entraîne la transmission sécurisée, depuis ledit récepteur et vers le module d’accès, de la donnée d’authentification.
- Selon un mode de réalisation : - les données d’application sont installées dans le récepteur numérique sous la forme d’une application publicitaire ou d’une application forçant le visionnage d’une annonce publicitaire ; - si l’application est arrêtée volontairement avant la fin de son exécution : le récepteur numérique cesse de transmettre la donnée d’authentification au module d’accès, et le module d’accès effectue au moins l’une des actions suivantes : cessation d’un traitement du flux multimédia ; cessation d’un transfert du flux multimédia au récepteur numérique ; cessation d’une transmission, au récepteur numérique, d’une ou plusieurs clés de décryptage du flux multimédia lorsque celui-ci est crypté ; limitation d’une transmission du flux multimédia au récepteur numérique, de sorte qu’une vidéo ou un programme contenu dans ledit flux s’affiche de manière limitée dans le temps, sur un écran connecté audit récepteur.
- Selon un mode de réalisation, le procédé comprend les étapes consistant à : - connecter le module d’accès au récepteur multimédia au moyen d’une connexion sécurisée, les données d’application et la au moins une donnée d’authentification étant transmises au travers de cette connexion ; - sécuriser la connexion en appliquant un chiffrement selon la norme DVB-CI+.
- Selon un mode de réalisation, le procédé comprend les étapes suivantes : - associer aux données d’application transmises au récepteur multimédia, plusieurs données d’authentification connues du module d’accès, laquelle association est réalisée dans ledit module ; - l’exécution de l’application, ou d’une fonction de ladite application, dans le récepteur multimédia, entraîne la transmission sécurisée, depuis ledit récepteur et vers le module d’accès, d’au moins une desdites données d’authentification ; - l’authentification de l’application est basée sur une comparaison, dans le module d’accès, de la donnée d’authentification transmise par le récepteur multimédia, aux données d’authentification connues dudit module.
- Selon un mode de réalisation, le procédé comprend les étapes suivantes : - horodater, dans le module d’accès, les données d’authentification destinées à être transmises au récepteur multimédia de manière à ce que lesdites données aient une période de validité limitée dans le temps ; - vérifier, dans le module d’accès, la période de validité de la donnée d’authentification transmise par le récepteur multimédia.
- Selon un mode de réalisation, le procédé comprend les étapes suivantes : - associer aux données d’application transmises au récepteur multimédia, une graine aléatoire adaptée pour initier un générateur de nombres pseudo-aléatoires installé dans ledit récepteur, lequel générateur est basé sur un algorithme connu du module d’accès, laquelle association est réalisée dans ledit module d’accès ; - l’exécution de l’application, ou d’une fonction de ladite application, dans le récepteur multimédia, entraîne la transmission sécurisée, depuis ledit récepteur et vers le module d’accès, d’au moins un nombre pseudo-aléatoire généré par le générateur de nombres pseudo-aléatoires ; - l’authentification de l’application est basée sur une comparaison, dans le module d’accès, du nombre pseudo-aléatoire transmis par le récepteur multimédia, à l’algorithme connu dudit module.
- Selon un mode de réalisation, le procédé comprend les étapes suivantes : - crypter le flux multimédia avant de le diffuser dans un réseau de diffusion ; - traiter le flux multimédia crypté dans le module d’accès, lequel traitement consiste à : -- décrypter le flux multimédia en fonction de droits d’accès enregistrés dans le module d’accès ; -- ajouter dans le flux multimédia décrypté, les données d’application ; -- chiffrer le flux multimédia contenant les données d’application ; - transmettre au travers de la connexion sécurisée, depuis le module d’accès et vers le récepteur multimédia, le flux multimédia traité ; - déchiffrer le flux multimédia traité dans le récepteur multimédia.
- Selon un mode de réalisation, le procédé comprend les étapes consistant à continuer à traiter le flux multimédia dans le module d’accès et/ou continuer à transférer le flux multimédia traité vers le récepteur multimédia, à la condition que la comparaison donne une correspondance entre la donnée d’authentification transmise par ledit récepteur et les données d’authentification connues dudit module.
- Selon un mode de réalisation, le procédé comprend les étapes consistant à continuer à traiter le flux multimédia dans le module d’accès et/ou continuer à transférer le flux multimédia traité vers le récepteur multimédia, à la condition que la période de validité de la donnée d’authentification transmise depuis ledit récepteur ne soit pas échue.
- Selon un mode de réalisation, le procédé comprend les étapes consistant à continuer à traiter le flux multimédia dans le module d’accès et/ou continuer à transférer le flux multimédia traité vers le récepteur multimédia, à la condition que la comparaison donne une correspondance entre le nombre pseudo-aléatoire transmis par ledit récepteur et l’algorithme connu dudit module.
- Selon un mode de réalisation, le procédé comprend les étapes suivantes : - crypter le flux multimédia avant de le diffuser dans un réseau de diffusion ; - réceptionner, par le récepteur multimédia, le flux multimédia crypté ; - après vérification des droits d’accès par le module d’accès, transmettre de manière sécurisée, depuis ledit module d’accès et vers le récepteur multimédia, une ou plusieurs clés de décryptage du flux multimédia crypté ; - décrypter, dans le récepteur multimédia, le flux multimédia avec la ou les clés de décryptage.
- Selon un mode de réalisation, le procédé comprend les étapes consistant à cesser de transmettre la ou les clés de décryptage au récepteur multimédia, si la comparaison ne donne pas une correspondance entre la donnée d’authentification transmise par ledit récepteur et les données d’authentification connues du module d’accès.
- Selon un mode de réalisation, le procédé comprend les étapes consistant à cesser de transmettre la ou les clés de décryptage au récepteur multimédia, si la période de validité de la donnée d’authentification transmise depuis ledit récepteur est échue.
- Selon un mode de réalisation, le procédé comprend les étapes consistant à cesser de transmettre la ou les clés de décryptage au récepteur multimédia, si la comparaison ne donne pas une correspondance entre le nombre pseudo-aléatoire transmis par ledit récepteur et l’algorithme connu du module d’accès.
- Selon un mode de réalisation, les données d’application sont adaptées pour être installées dans le récepteur multimédia sous la forme d’une application HbbTV.
- Selon un mode de réalisation, le procédé comprend les étapes le flux multimédia contient une vidéo et les données d’application intègre une fonction de marquage de vidéo, ledit procédé comprenant les étapes consistant à : - inclure des données de marquage de la vidéo dans les données d’application transmises au récepteur multimédia ; - réaliser le marquage de la vidéo en fonction des données de marquage, au moyen de la fonction de marquage de l’application exécutée dans le récepteur multimédia ; - le marquage de la vidéo dans le récepteur multimédia, entraîne la transmission sécurisée, depuis ledit récepteur et vers le module d’accès, de la donnée d’authentification.
- Selon un mode de réalisation : - les données d’application sont installées dans le récepteur numérique sous la forme d’une application publicitaire ou d’une application forçant le visionnage d’une annonce publicitaire ; - si l’application est arrêtée volontairement avant la fin de son exécution : le récepteur numérique cesse de transmettre la donnée d’authentification au module d’accès, et le module d’accès effectue au moins l’une des actions suivantes : cessation d’un traitement du flux multimédia ; cessation d’un transfert du flux multimédia au récepteur numérique ; cessation d’une transmission, au récepteur numérique, d’une ou plusieurs clés de décryptage du flux multimédia lorsque celui-ci est crypté ; limitation d’une transmission du flux multimédia au récepteur numérique, de sorte qu’une vidéo ou un programme contenu dans ledit flux s’affiche de manière limitée dans le temps, sur un écran connecté audit récepteur.
- Selon un mode de réalisation, le procédé comprend les étapes consistant à : - connecter le module d’accès au récepteur multimédia au moyen d’une connexion sécurisée, les données d’application et la au moins une donnée d’authentification étant transmises au travers de cette connexion ; - sécuriser la connexion en appliquant un chiffrement selon la norme DVB-CI+.
Un autre aspect de l’invention concerne un système comportant un module d’accès et un récepteur multimédia, configurés pour la mise en œuvre des étapes du procédé selon l’une des caractéristiques précédentes.
Encore un autre aspect de l’invention concerne un produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé selon l’une des caractéristiques précédentes, lorsqu'il est exécuté par un module d’accès connecté à un récepteur multimédia.
Brève description des figures.
D’autres avantages et caractéristiques de l’invention apparaîtront mieux à la lecture de la description d’un mode de réalisation préféré qui va suivre, en référence aux dessins annexés, réalisés à titre d’exemples indicatifs et non limitatifs et sur lesquels :
illustre un système pour la mise en œuvre du procédé de l’invention, selon un premier mode de réalisation,
illustre un système pour la mise en œuvre du procédé de l’invention, selon un second mode de réalisation.
Description des modes de réalisation.
Le procédé et le système objets de l’invention engendrent des manipulations d’éléments physiques, notamment des signaux (électriques ou magnétiques) et des données numériques, capables d'être stockés, transférés, combinés, comparés, …, et permettant d’aboutir à un résultat souhaité.
L’invention met en œuvre une ou plusieurs applications informatiques exécutées par des équipements informatiques (module d’accès, récepteur multimédia …). Par souci de clarté, il faut comprendre au sens de l’invention que «u n équipement fait quelque chose» signifie «l'application informatique exécutée par une unité de traitement de l’équipement fait quelque chose». Tout comme «l'application informatique fait quelque chose» signifie «l'application informatique exécutée par l’unité de traitement de l’équipement fait quelque chose».
Encore par souci de clarté, la présente invention fait référence à un ou plusieurs «processus informatiques». Ces derniers correspondent aux actions ou résultats obtenus par l’exécution d’instructions de différentes applications informatiques. Aussi, il faut également comprendre au sens de l’invention que «un processus informatique est adapté pour faire quelque chose» signifie «les instructions d’une application informatique exécutées par une unité de traitement font quelque chose».
Encore par souci de clarté, les précisions suivantes sont apportées à certains termes utilisés dans la description et les revendications :
- «Ressource informatique» peut être compris de façon non limitative comme : composant, matériel, logiciel, fichier, connexion à un réseau informatique, quantité de mémoire RAM, espace de disque dur, bande passante, vitesse de processeur, nombre de CPU, etc.
- «Serveur informatique» peut être compris de façon non limitative comme : dispositif informatique (matériel ou logiciel) comportant des ressources informatiques pour réaliser les fonctions d’un serveur et qui offre des services, ordinateur, pluralité d’ordinateurs, serveur virtuel sur internet, serveur virtuel sur Cloud, serveur virtuel sur une plate-forme, serveur virtuel sur une infrastructure locale, réseaux de serveurs, cluster, nœud, ferme de serveurs, ferme de nœuds, etc.
- «Unité de traitement» peut être compris de façon non limitative comme : processeur, microprocesseurs, CPU (pour Central Processing Unit), etc.
- «Application informatique» peut être comprise comme : logiciel, programme informatique, micros-programme informatique, lignes de codes exécutables, software, etc.
- «Réseau de diffusion» peut être compris de façon non limitative comme : réseau internet, réseau cellulaire, réseau satellite, etc. C’est un ensemble d'équipements informatiques reliés entre eux pour échanger, de manière sécurisée ou non, des informations et/ou des données selon un protocole de communication (ISDN, Ethernet, ATM, IP, CLNP, TCP, HTTP, …).
- «Récepteur multimédia» peut être défini comme un téléviseur, un décodeur, un téléphone intelligent (Smartphone), un ordinateur personnel fixe ou portable, une tablette ou tout autre appareil configuré pour recevoir, traiter et restituer du contenu multimédia.
- Tel qu’utilisé ici, sauf indication contraire, l’utilisation des adjectifs ordinaux «premier», «deuxième», etc., pour décrire un objet indique simplement que différentes occurrences d’objets similaires sont mentionnées et n’implique pas que les objets ainsi décrits doivent être dans une séquence donnée, que ce soit dans le temps, dans l'espace, dans un classement ou de toute autre manière.
- «Ressource informatique» peut être compris de façon non limitative comme : composant, matériel, logiciel, fichier, connexion à un réseau informatique, quantité de mémoire RAM, espace de disque dur, bande passante, vitesse de processeur, nombre de CPU, etc.
- «Serveur informatique» peut être compris de façon non limitative comme : dispositif informatique (matériel ou logiciel) comportant des ressources informatiques pour réaliser les fonctions d’un serveur et qui offre des services, ordinateur, pluralité d’ordinateurs, serveur virtuel sur internet, serveur virtuel sur Cloud, serveur virtuel sur une plate-forme, serveur virtuel sur une infrastructure locale, réseaux de serveurs, cluster, nœud, ferme de serveurs, ferme de nœuds, etc.
- «Unité de traitement» peut être compris de façon non limitative comme : processeur, microprocesseurs, CPU (pour Central Processing Unit), etc.
- «Application informatique» peut être comprise comme : logiciel, programme informatique, micros-programme informatique, lignes de codes exécutables, software, etc.
- «Réseau de diffusion» peut être compris de façon non limitative comme : réseau internet, réseau cellulaire, réseau satellite, etc. C’est un ensemble d'équipements informatiques reliés entre eux pour échanger, de manière sécurisée ou non, des informations et/ou des données selon un protocole de communication (ISDN, Ethernet, ATM, IP, CLNP, TCP, HTTP, …).
- «Récepteur multimédia» peut être défini comme un téléviseur, un décodeur, un téléphone intelligent (Smartphone), un ordinateur personnel fixe ou portable, une tablette ou tout autre appareil configuré pour recevoir, traiter et restituer du contenu multimédia.
- Tel qu’utilisé ici, sauf indication contraire, l’utilisation des adjectifs ordinaux «premier», «deuxième», etc., pour décrire un objet indique simplement que différentes occurrences d’objets similaires sont mentionnées et n’implique pas que les objets ainsi décrits doivent être dans une séquence donnée, que ce soit dans le temps, dans l'espace, dans un classement ou de toute autre manière.
Un système pour la mise en œuvre du procédé selon l’invention comprend un module d’accès connecté à un récepteur multimédia.
Système : premier mode de réalisation (fi g ure 1)
Système : premier mode de réalisation (fi g ure 1)
Selon le premier mode de réalisation illustré par la figure 1, un flux multimédia 1 à accès contrôlé est diffusé dans un réseau de diffusion de manière compressée. Le réseau de diffusion peut être unidirectionnel (DVB, DVB-T, DVB-S, DVB-C, DVB-I, 5G broadcast, …) et/ou bidirectionnel (internet, LAN, W-LAN, …).
Le flux multimédia 1 (généralement désigné par le terme anglais «Transport Stream») contient un contenu multimédia dont notamment une vidéo à marquer. Ce contenu multimédia est avantageusement crypté ou embrouillé au niveau d’un point de diffusion D, avant d'être diffusé. Ce point de diffusion D appartient par exemple à un système de diffusion d’un opérateur.
Le cryptage consiste préférentiellement en un codage cryptographique du contenu multimédia empêchant sa réception ou sa lecture par un utilisateur non autorisé. Son accès est en effet généralement soumis à des droits (paiement d'une taxe, condition d'âge, ....) que doivent acquérir spécifiquement les utilisateurs. Un utilisateur final autorisé dispose d’une clé de décryptage, ou habilitation, permettant de décrypter le contenu multimédia. Ce décodage cryptographique est un processus informatique géré par le module d’accès décrit plus avant dans la description.
Le récepteur multimédia 2 reçoit le flux multimédia 1 au niveau d’une interface 21. Cette dernière peut consister en un syntoniseur/démodulateur intégré dans le récepteur multimédia 2. L’interface 21 peut également se présenter sous la forme d'un décodeur ou d'un boîtier de connexion du type Box internet ou Set-Top-Box connecté au récepteur multimédia 2 par une connexion sans fil (Wifi, Bluetooth, ou autres) ou filaire (USB, Ethernet, ou autres). Le flux multimédia reçu par le récepteur multimédia 2 est ensuite transmis au module d’accès 3 pour une vérification des droits d’accès.
Selon un mode de réalisation, le module d’accès 3 est connecté physiquement au récepteur multimédia 2. Selon un exemple de réalisation, le module d’accès 3 est un module d’accès conditionnel CAM se présentant sous la forme d'un boîtier amovible pourvu d'un connecteur PCMCIA 32 (pour l'acronyme anglais Personal Computer Memory Card International Association). Ce connecteur 32 est adapté pour se connecter sur un connecteur PCMCIA complémentaire 22 installé sur le récepteur multimédia 2. Le module CAM 3 intègre un lecteur de carte à puce qui coopère avec une carte à puce dans laquelle sont enregistrés les droits d’accès de l’utilisateur permettant de décrypter la vidéo. De manière générale, la communication entre le module d’accès 3 et le récepteur multimédia 2 se fait au travers de la connexion 22, 32.
D'autres types de modules d’accès 3 peuvent être utilisés, notamment un module d’accès amovible se présentant sous la forme d’une clé USB (pour l’acronyme anglais Universal Serial Bus) dans laquelle sont enregistrés les droits d’accès de l’utilisateur, ou sous la forme d’un dispositif directement intégré dans le récepteur multimédia 2.
Dans le mode de réalisation de la figure 1, le processus informatique de décryptage du contenu multimédia est réalisé dans le module d’accès 3, par un module de contrôle d’accès 30, généralement désigné par agent CAS (pour l'acronyme anglais Conditional Access System). Par exemple, les données de la vidéo sont cryptées avec une clé de cryptage. La clé de cryptage est transmise avec le flux multimédia 1 en tant que message de contrôle d'habilitation (ECM). L’agent CAS 30 déchiffre la clé de cryptage uniquement lorsqu'il est autorisé à le faire par réception d'un message de gestion d'habilitation (EMM) spécifique à l’utilisateur final. L’agent CAS 30 confirme les droits d'accès fournis par le message EMM en comparant un identifiant utilisateur contenu dans le message EMM avec identifiant utilisateur stocké dans ledit module (carte à puce, zone mémoire, …). En cas de confirmation, l’agent CAS 30 décrypte le flux multimédia 1.
Des données de marquage sont ajoutées au flux multimédia, le cas échéant après le décryptage dudit flux si celui-ci est initialement crypté. Cette opération est réalisée dans le module d’accès 3, par une unité de traitement 31. Selon un mode de réalisation, une instruction de marquage est transmise avec le flux multimédia 1 lors de sa diffusion dans le réseau de diffusion. Lorsque le module d’accès 3 réceptionne le flux multimédia 1, il détecte cette instruction de marquage et procède à l’ajout des données de marquage. L’ajout des données marquage au flux multimédia peut être réalisé une seule fois, au début de sa réception par le module d’accès 3. L’ajout peut également être réalisé de manière continue, tant que le flux multimédia transite par le module d’accès 3.
Selon un mode de réalisation, les données de marquage consistent en une image ou autre signe graphique adapté pour se superposer aux images de la vidéo, comme un calque. Ces données sont par exemple regroupées dans un ou plusieurs fichiers PNG (pour l'acronyme anglais Portable Network Graphics) ou GIF (pour l'acronyme anglais Graphics Interchange Format) ou JPEG (pour l'acronyme anglais Joint Photographic Experts Group). Les données de marquage peuvent également consister en un texte, ou une combinaison d’une image (ou signe graphique) et d’un texte. Quel que soit le format utilisé, les données de marquage ont un poids relativement réduit, allant de quelques octets à quelques kilo-octets. Les données de marquage sont enregistrées dans une zone mémoire 33 du module d’accès 3. Elles peuvent par exemple être enregistrées nativement lors de la fabrication du module d’accès 3, ou être téléchargées ultérieurement durant une phase d'initialisation dudit module, ou être générées à la volée au moyen d’un algorithme et/ou ou de métadonnées transmises avec le flux multimédia 1 lors de sa diffusion dans le réseau de diffusion .
Les données de marquage peuvent être fixes (la même marque est appliquée sur la vidéo) ou variables (des marques différentes sont appliquées sur la vidéo). Dans ce dernier cas, les instructions de marquage incluses dans flux multimédia 1 peuvent être associées à des données temporelles (ou « Timestamp » en anglais). Lorsque le module d’accès 3 réceptionne le flux multimédia 1, il modifie les données de marquage selon les données temporelles (par exemple les données de marquage sont modifiées toutes les 100 ms).
Selon un mode de réalisation, pour sécuriser la communication entre le module d’accès 3 et le récepteur multimédia 2, le flux multimédia contenant les données de marquage est chiffré avant d’être renvoyé audit récepteur. Le chiffrement est réalisé par un module de chiffrement 34 du module d’accès 3. Ce chiffrement est préférentiellement réalisé selon la norme DVB-CI+ (aussi connue sous le nom de CI Plus ou Common Interface Plus). La norme DVB-CI+ est bien connue de l’homme du métier et s’avère particulièrement robuste contre les attaques. L’homme du métier-ci pourra se référer, en cas de besoin, aux documents décrivant les différentes spécifications de cette norme sur le site internet : http://www.ci-plus.com/documentation. Pour assurer cette communication chiffrée, on peut notamment utiliser un module d’accès CAM DVB-CI+ (référencé dans les spécifications en tant que CICAM). Selon une variante de réalisation, un autre type de chiffrement est utilisé, par exemple un chiffrement basé sur le protocole DHCP (pour l’acronyme anglais Dynamic Host Configuration Protocol), ou sur le protocole DTCP (pour l’acronyme anglais Digital Transmission Content Protection) ou sur le protocole SSL (pour l’acronyme anglais Secure Soket Layer). Les données de marquage étant communiquées de manière chiffrée au récepteur multimédia 2, il est difficile de les intercepter et de les découvrir entre le module d’accès 3 et ledit récepteur.
Le flux multimédia 10 renvoyé au récepteur multimédia 2 est déchiffré par un module de déchiffrement 23, puis démultiplexé par un démultiplexeur 24 pour extraire la vidéo. Celle-ci est ensuite décodée par un décodeur 25. Le démultiplexeur 24 démultiplexe en outre les données de marquage transmises par le module d’accès 3. Une fois démultiplexées, les données de marquage sont traitées par une unité de traitement 26. Cette dernière réalise le marquage de la vidéo en fonction des données de marquage. Ce marquage est par exemple réalisé au moyen d’une application de marquage qui peut être une fonction d’une application HbbTV déjà enregistrée dans le récepteur multimédia 2. Selon un mode de réalisation, la marque est superposée aux images de la vidéo. La vidéo ainsi marquée peut alors être restituée, par exemple sur un écran 27 intégré ou associé au récepteur multimédia 2.
Les données de marquage ajoutées au flux multimédia, sont avantageusement incluses dans des données d’application. L’application est une application de watermarking et préférentiellement une application HbbTV intégrant une fonction de watermaking. C’est donc le module d’accès 3 qui transmet au récepteur multimédia 2 les ressources informatiques permettant de réaliser le watermaking, et éventuellement les autres fonctions d’une application HbbTV.
Dans l’art antérieur, les données d’application HbbTV peuvent être téléchargées dans le récepteur multimédia 2, depuis un serveur distant, au travers d’une connexion internet. En l’absence de connexion internet, il n’est donc pas possible de télécharger les données d’application HbbTV. La transmission des données d’application depuis le module d’accès 3 permet de résoudre cet inconvénient dans la mesure où même si le récepteur multimédia 2 n’est pas connecté au réseau internet, il pourra quand même bénéficier de l’application HbbTV.
Dans le cas où les données d’application HbbTV sont intégrées dans le flux multimédia 1, ces données ne sont généralement pas sécurisées (ce qui peut également être le cas lors d’un téléchargement depuis un serveur distant). Aussi, il existe des risques que ces données d’application HbbTV soient interceptées et piratées. La transmission des données d’application HbbTV depuis le module d’accès 3 est beaucoup plus sécurisée. En effet, ces données d’application sont préférentiellement enregistrées dans la zone mémoire 33, lors de la fabrication du module d’accès 3 ou suite à une mise à jour par un canal sécurisé (ex : VPN ou OTA sécurisé), de sorte que les risques de piratage sont fortement réduits, voire nuls. En outre, le chiffrement réalisé par le module de chiffrement 34, et plus particulièrement un chiffrement réalisé selon la norme DVB-CI+, fournit une mesure de sûreté additionnelle garantissant que seul le récepteur multimédia 2 a accès à ces données.
Selon un mode de réalisation, les données d’application HbbTV intégrant la fonction de watermaking sont regroupées dans un ou plusieurs fichiers HTML (pour HyperText Markup Language) et/ou JavaScript qui s’ajoutent aux fichiers PNG, GIF ou JPEG des données de marquage. Ici encore, l’ensemble de ces fichiers a un poids relativement réduit, qui ne nécessite pas de rajouter des ressources informatiques supplémentaires aux modules d’accès 3, ni d’augmenter le débit de la connexion entre ledit module et le récepteur multimédia 2.
Après réception, par le récepteur multimédia 2, du flux multimédia traité 10, le démultiplexeur 24 démultiplexe la vidéo et les données d’applications. Celles-ci sont traitées par l’unité de traitement 26 et installées sous forme d’application HbbTV. Le watermaking de la vidéo est alors exécuté par la fonction de marquage de l’application HbbTV.
Il est avantageux de s’assurer que le récepteur multimédia 2 n’a pas été piraté, auquel cas le watermaking pourrait ne pas être appliqué à la vidéo. Aussi, une mesure de sécurité additionnelle est avantageusement prévue pour que le module d’accès 3 s’assure que le watermaking est effectivement appliqué à la vidéo. Cette solution consiste à créer un lien de confiance entre le récepteur multimédia 2 et le module d’accès 3. Lorsque le récepteur multimédia 2 a marqué la vidéo, il transmet automatiquement au module d’accès 3, au travers de la connexion sécurisée 22-32, au moins une donnée d’authentification identifiable par ledit module d’accès. Si le module d’accès 3 identifie cette donnée d’authentification, alors il peut authentifier que le marquage de la vidéo a bien été réalisé par le récepteur multimédia 2.
Selon un mode de réalisation, on associe aux données de marquages transmises au récepteur multimédia 2, plusieurs données d’authentification connues du module d’accès 3. Cette association est réalisée dans le module d’accès 3, par l’unité de traitement 31, par exemple en même temps que l’ajout des données de marquage et/ou des données d’application.
Les données d’authentification se présentent par exemple sous la forme d’une ou plusieurs séries de codes numériques ou alphanumériques générés de manière pseudo-aléatoire et préalablement enregistrés dans la zone mémoire 33 du module d’accès 3. Lorsque le récepteur multimédia 2 reçoit le flux traité par le module d’accès 3, il reçoit également ces données d’authentification. Ces dernières sont assimilables à un secret partagé entre le récepteur multimédia 2 et le module d’accès 3.
Les données d’authentification peuvent être transmises une seule fois au récepteur multimédia 2 ou de manière continue pendant toute la durée de traitement du flux multimédia par le module d’accès 3. Selon une variante de réalisation, différentes séries de données d’authentification sont transmises à différents instants. Par exemple, une première série est transmise à un instant T1, une deuxième série à un instant T2 (>T1), une troisième série à un instant T3 (>T2), et ainsi de suite pendant toute la durée du traitement du flux multimédia par le module d’accès 3.
Le marquage de la vidéo dans le récepteur multimédia 2 entraîne la transmission d’une ou plusieurs données d’authentification au module d’accès 3. Cette transmission est réalisée automatiquement par le récepteur multimédia 2, au travers de la connexion sécurisée 22, 32. Cette transmission est préférentiellement réalisée de manière continue ou récurrente, pendant toute la durée du watermaking de la vidéo par le récepteur multimédia 2.
Lorsque le module d’accès 3 reçoit une donnée d’authentification, il la compare aux données d’authentification qu’il connait et qui sont enregistrées dans sa zone mémoire 33. Si une correspondance est établie entre la donnée d’authentification reçue et une donnée d’authentification connue, alors le module d’accès 3 authentifie le marquage de la vidéo. En d’autres termes, le module d’accès 3 est assuré que le watermaking de la vidéo a bien été réalisé dans le récepteur multimédia 2. Le module d’accès 3 continue alors de traiter normalement le flux multimédia. Si la correspondance n’est pas établie, le module d’accès 3 cesse de traiter le flux multimédia 1 (arrêtant notamment de le décrypter) et/ou cesse de transférer le flux multimédia traité 10 vers le récepteur multimédia 2 : la vidéo ne s’affiche plus, ou de manière cryptée, sur l’écran 27. Ce cas peut par exemple se produire si un attaquant lance, depuis le récepteur multimédia 2, une application fictive de watermaking.
Le module d’accès 3 peut également être configuré pour horodater les données d’authentification qu’il transmet, de manière à ce que lesdites données aient une période de validité limitée dans le temps. Le module d’accès 3 vérifie cette période de validité lorsqu’il reçoit une donnée d’authentification émise par le récepteur multimédia 2. Aussi, si le récepteur multimédia 2 renvois au module d’accès 3, la bonne donnée d’authentification, mais en dehors de sa période de validité (donnée d’authentification échue), ledit module cesse de traiter le flux multimédia 1 et/ou cesse de transférer le flux multimédia traité 10 vers ledit récepteur : la vidéo ne s’affiche plus, ou de manière cryptée, sur l’écran 27. Ce cas peut par exemple se produire si un attaquant renvois au module d’accès 3 des données d’authentification issues d’un autre module d’accès piraté ou d’un autre récepteur piraté.
Le module d’accès 3 peut également être configuré pour attendre la réception d’une donnée d’authentification transmise par le récepteur multimédia 2. Si le module d’accès 3 ne reçoit aucune donnée d’authentification, il cesse de traiter le flux multimédia et/ou cesse de le transférer vers le récepteur multimédia 2. La vidéo cesse de s’afficher sur l’écran 27. Ce cas peut par exemple se produire si un attaquant intercepte le flux multimédia traité, à la sortie du module d’accès 3, et extrait dudit flux les données de marquage (et/ou les données d’application). En enlevant ces données, l’attaquant enlèvera également les données d’authentification qui, de fait ne pourront plus être retransmises au module d’accès 3.
Selon une variante de réalisation, le module d’accès 3 associe aux données de marquage transmises au récepteur multimédia 2, une graine aléatoire (ou « Seed » en anglais) adaptée pour initier un générateur de nombres pseudo-aléatoires 28 installé dans ledit récepteur. Ce générateur 28 est basé sur un algorithme connu du module d’accès. L’algorithme est ici le secret partagé entre le récepteur multimédia 2 et le module d’accès 3. Ce dernier est capable de générer un ou plusieurs nombres pseudo-aléatoires initiés par la graine aléatoire.
Lorsque le récepteur multimédia 2 reçoit le flux traité par le module d’accès 3, il reçoit également la graine aléatoire. Le générateur 28 va alors générer un ou plusieurs nombres pseudo-aléatoires. Le marquage de la vidéo dans le récepteur multimédia 2 entraîne la transmission, au module d’accès 3, d’au moins un nombre pseudo-aléatoire ainsi généré. Cette transmission est réalisée automatiquement par le récepteur multimédia 2, au travers de la connexion sécurisée 22, 32, de manière continue ou récurrente (un nouveau nombre pseudo-aléatoire étant envoyé à chaque occurrence), pendant toute la durée du watermaking de la vidéo par ledit récepteur.
Lorsque le module d’accès 3 reçoit un nombre pseudo-aléatoire, il le compare à l’algorithme qu’il connait. Connaissant l’algorithme du générateur 28 et la graine aléatoire qu’il a envoyée, le module d’accès 3 est capable de déterminer si le nombre pseudo-aléatoire a bien été généré par cet algorithme à partir de cette graine. Selon un mode de réalisation, le module d’accès 3 compare les nombres pseudo-aléatoires transmis par le récepteur numérique 2, avec les nombres pseudo-aléatoires que ledit module à lui-même initié avec la graine aléatoire. Les actions réalisées par le module d’accès si la correspondance est établie ou pas, sont similaires à celles décrites précédemment.
De même, comme décrit précédemment : - les nombres pseudo-aléatoires transmis par le récepteur multimédia 2 peuvent être horodatés ; - le module d’accès 3 peut être configuré pour attendre la réception d’un nombre pseudo-aléatoire. Si le module d’accès 3 reçoit un nombre pseudo-aléatoire dont la période de validité est échue et/ou s’il ne reçoit pas de nombre pseudo-aléatoire, les actions réalisées par ledit module sont similaires à celles décrites précédemment.
Le même processus d’authentification, basé sur l’échange de données d’authentification ou sur l’échange d’une graine aléatoire et de nombres pseudo-aléatoires, est avantageusement mis en œuvre dès qu’une fonction de l’application HbbTV (dont la fonction de watermaking) est exécutée par le récepteur multimédia 2. Le module d’accès 3 est ainsi assuré que c’est la bonne application HbbTV qui est exécutée dans le récepteur multimédia 2, et pas une application HbbTV piratée ou malveillante.
Système : second mode de réalisation (figure 2)
Système : second mode de réalisation (figure 2)
Dans le second mode de réalisation illustré par la figure 2, le module d’accès 3 est distant du récepteur multimédia 2. Il est par exemple intégré dans un serveur informatique distant du récepteur multimédia 2, ledit module faisant partie des ressources informatiques dudit serveur. La connexion entre le module d’accès 3 et le récepteur multimédia 2 peut être une connexion peut être sécurisée ou non sécurisée, par exemple une connexion internet ou via un réseau de téléphonie mobile, ou une connexion de type VPN (pour l’acronyme anglais Virtual Private Network) pour sécuriser l’échange de données entre ces éléments.
Le contrôle d’accès est effectué par l’agent CAS 30 du module d’accès 3, mais le processus informatique de décryptage du contenu multimédia est réaliséin situ, dans le récepteur multimédia 2.
Le récepteur multimédia 2 reçoit le flux multimédia 1 au niveau de l’interface 21. Un démultiplexeur 240 extrait du flux multimédia, le message de contrôle d'habilitation ECM, et transmet celui-ci au module d’accès 3. L’agent CAS 30 confirme les droits d'accès, notamment après analyse des messages ECM et EMM.
Après confirmation des droits d'accès, l’unité de traitement 31 transmet une ou plusieurs clés de décryptage KEY au récepteur multimédia 2. Cette transmission est préférentiellement réalisée de manière sécurisée au travers d’une connexion CS, par exemple au moyen d’une connexion sécurisée de type VPN ou d’une connexion internet sécurisée utilisant un protocole de transfert sécurisé de type HTTPS (pour l’acronyme anglais Hypertext Transfer Protocol Secure), ou en transmettant la ou les clés de décryptage KEY de manière cryptée et/ou authentifiée, au travers d’une connexion non sécurisée. Selon une variante de réalisation, la ou les clés de décryptage KEY sont transmises de manière non sécurisée. Il s’agit dans ce cas d’une clé unique associée au seul récepteur multimédia 2. En d’autres termes, seul le récepteur multimédia 2 peut interpréter la ou les clés KEY.
La ou les clés de décryptage KEY sont avantageusement transmises de manière régulière (par exemple toutes les 5 secondes) au récepteur multimédia 2, pour les raisons expliquées plus avant dans la description.
Le module d’accès 3 transmet également au récepteur multimédia 2, les données de marquage DM, au travers de la connexion CS. La transmission de la ou les clés de décryptage KEY et celle des données de marquage DM peuvent être simultanées ou pas.
Comme décrit précédemment en référence au premier mode de réalisation, les données de marquage peuvent être incluses dans des données d’application (notamment HbbTV). De même, des données d’authentification ou une graine aléatoire, peuvent être associées aux données de marquage.
Dans le récepteur multimédia 2, un module de décryptage 230 décrypte le flux multimédia 1 en utilisant la ou les clés KEY reçues du module d’accès 3. Le flux multimédia est ensuite démultiplexé par un démultiplexeur 24 pour extraire la vidéo. Celle-ci est ensuite décodée par un décodeur 25. L’unité de traitement 26 réalise le marquage de la vidéo en fonction des données de marquage DM reçues du module d’accès 3. La vidéo ainsi marquée est restituée sur l’écran 27.
Le processus de création d’un lien de confiance entre le récepteur multimédia 2 et le module d’accès 3 est similaire à celui décrit en référence au premier mode de réalisation (notamment transmission des données d’authentification ou de la graine aléatoire, au travers de la connexion CS, entre le module d’accès 3 et le récepteur multimédia 2).
En particulier, le module d’accès 3 cesse de transmettre la ou les clés de décryptage KEY au récepteur multimédia 2, dans les cas suivants :
- absence de correspondance entre la donnée d’authentification transmise par le récepteur multimédia 2 et les données d’authentification connues du module d’accès 3.
- la période de validité de la donnée d’authentification transmise depuis le récepteur multimédia 2 est échue.
- absence de correspondance entre le nombre pseudo-aléatoire transmis par le récepteur multimédia 2 et l’algorithme connu du module d’accès 3.
Dans ces cas, la vidéo ne s’affiche plus, ou de manière cryptée, sur l’écran 27.
Autres applications, ou fonctions d’application , pouvant être authentifiées
- absence de correspondance entre la donnée d’authentification transmise par le récepteur multimédia 2 et les données d’authentification connues du module d’accès 3.
- la période de validité de la donnée d’authentification transmise depuis le récepteur multimédia 2 est échue.
- absence de correspondance entre le nombre pseudo-aléatoire transmis par le récepteur multimédia 2 et l’algorithme connu du module d’accès 3.
Dans ces cas, la vidéo ne s’affiche plus, ou de manière cryptée, sur l’écran 27.
Autres applications, ou fonctions d’application , pouvant être authentifiées
Les processus d’authentification décrits précédemment, peuvent être mis en œuvre pour authentifier tout type d’application, ou de fonction d’application, exécutée par le récepteur multimédia 2.
Selon un mode de réalisation, les données d’application transmises par le module d’accès 3 sont installées dans le récepteur numérique 2 sous la forme d’une application publicitaire. Cette application peut être une application à part entière, ou une fonction d’une autre application, notamment une application HbbTV. Ce type d’application – ou de fonction - permet par exemple d’afficher une annonce ou un message publicitaire (personnalisé ou générique), éventuellement en rapport avec le comportement de l’utilisateur. Une ou plusieurs annonces publicitaires sont par exemple systématiquement affichées sur l’écran 27 avant la lecture d’une vidéo ou d’un programme télévisé.
Tant que l’application est exécutée correctement, le récepteur numérique 2 transmet une ou plusieurs données d’authentification qui sont identifiées par le module d’accès 3 selon un processus décrit précédemment. Le module d’accès 3 continu alors de traiter le flux multimédia et/ou continu de transférer le flux multimédia traité vers le récepteur multimédia et/ou continu à lui transmettre la ou les clés de décryptage KEY, de sorte qu’une vidéo ou un programme sélectionné par l’utilisateur peut être joué. Par contre, si le récepteur numérique 2 et/ou l’application sont piratés, ou que l’application est arrêtée volontairement avant la fin de son exécution par l’utilisateur, par exemple dans le but de bloquer systématiquement toute annonce publicitaire, alors l’application n’est plus authentifiée par le module d’accès 3, le récepteur numérique 2 cessant de transmettre la donnée d’authentification. Le module d’accès 3 cesse alors de traiter et/ou de transférer le flux multimédia et/ou cesse la transmission de la ou des clés de décryptage KEY et/ou limite la transmission du flux multimédia, de sorte que la vidéo ou le programme ne s’affiche pas, ou de manière cryptée, ou de manière limitée dans le temps, sur l’écran 27.
Selon un autre mode de réalisation, les données d’application transmises par le module d’accès 3 sont installées dans le récepteur numérique 2 sous la forme d’une application forçant le visionnage d’une annonce publicitaire. Tans que l’annonce publicitaire est visionnée sur l’écran 27, alors le récepteur numérique 2 transmet une ou plusieurs données d’authentification qui sont identifiées par le module d’accès 3 selon un processus décrit précédemment. Si l’utilisateur zappe l’annonce publicitaire, alors le récepteur numérique 2 cesse de transmettre les données d’authentification, de sorte que le module d’accès 3 ne peut plus authentifier cette application. Le module d’accès 3 cesse alors de traiter et/ou de transférer le flux multimédia, et/ou cesse la transmission de la ou des clés de décryptage KEY, et/ou limite la transmission du flux multimédia, de sorte que la vidéo ou le programme ne s’affiche pas, ou de manière cryptée, ou de manière limitée dans le temps, sur l’écran 27.
Produit programme d’ordinateur
Produit programme d’ordinateur
Selon encore un autre aspect, l'invention concerne un produit programme d'ordinateur comprenant des instructions de code pour l'exécution du procédé selon l’invention, lorsqu'il est exécuté par un module d’accès 3 connecté à un récepteur multimédia 2.
L’agencement des différents éléments et/ou moyens et/ou étapes de l’invention, dans les modes de réalisation décrits ci-dessus, ne doit pas être compris comme exigeant un tel agencement dans toutes les implémentations. Notamment :
- Dans le premier mode de réalisation, le module d’accès 3 peut être connecté au récepteur numérique 2, au moyen d’une liaison sans fil de courte portée du type Wifi par exemple.
- Les données de marquage sont préférentiellement intégrées dans des données d’application HbbTV. Toutefois, elles peuvent être intégrées dans des données d’autres types d’applications permettant de bénéficier de services interactifs avec des programmes de chaînes TV. Il peut par exemple s’agir de données d’application MHEG (pour l’acronyme anglais « Multimedia and Hypermedia Experts Group »), ou de données d’application MHP (pour l’acronyme anglais « Multimedia Home Platform »).
- Des données de marquage ne sont pas nécessairement intégrées dans les données d’application. Le module d’accès 3 peut simplement transmettre au récepteur multimédia 2, les données d’application, intégrant éventuellement les données d’authentification ou la graine aléatoire.
- Dans le premier mode de réalisation, le module d’accès 3 peut être connecté au récepteur numérique 2, au moyen d’une liaison sans fil de courte portée du type Wifi par exemple.
- Les données de marquage sont préférentiellement intégrées dans des données d’application HbbTV. Toutefois, elles peuvent être intégrées dans des données d’autres types d’applications permettant de bénéficier de services interactifs avec des programmes de chaînes TV. Il peut par exemple s’agir de données d’application MHEG (pour l’acronyme anglais « Multimedia and Hypermedia Experts Group »), ou de données d’application MHP (pour l’acronyme anglais « Multimedia Home Platform »).
- Des données de marquage ne sont pas nécessairement intégrées dans les données d’application. Le module d’accès 3 peut simplement transmettre au récepteur multimédia 2, les données d’application, intégrant éventuellement les données d’authentification ou la graine aléatoire.
En outre, une ou plusieurs caractéristiques et/ou étapes exposées seulement dans un mode de réalisation peuvent être généralisées à l’autre mode de réalisation. De même, une ou plusieurs caractéristiques et/ou étapes exposées seulement dans un mode de réalisation peuvent être combinées avec une ou plusieurs autres caractéristiques et/ou étapes exposées seulement dans l’autre mode de réalisation.
Claims (18)
- Procédé pour authentifier une application informatique, ou l’une de ses fonctions, exécutée par un récepteur multimédia (2), ledit procédé comprenant les étapes suivantes :
- connecter un module d’accès (3) au récepteur multimédia (2), lequel module d’accès est adapté pour vérifier des droits d’accès à un flux multimédia (2) à accès contrôlé réceptionné dans ledit récepteur numérique,
- enregistrer des données d’application dans le module d’accès (3),
- transmettre de manière sécurisée, depuis le module d’accès (3) et vers le récepteur multimédia (2), les données d’application,
- installer, dans le récepteur multimédia (2), les données d'application sous la forme de l’application,
- l’exécution de l’application, ou d’une fonction de ladite application, dans le récepteur multimédia (2), entraîne une transmission sécurisée, depuis ledit récepteur et vers le module d’accès (3), d’au moins une donnée d’authentification identifiable par ledit module d’accès,
- authentifier l’application exécutée par le récepteur multimédia (2), laquelle authentification est basée sur l’identification, dans le module d’accès (3), de la donnée d’authentification transmise par ledit récepteur multimédia. - Procédé selon la revendication 1, comprenant les étapes suivantes :
- associer aux données d’application transmises au récepteur multimédia (2), plusieurs données d’authentification connues du module d’accès (3), laquelle association est réalisée dans ledit module,
- l’exécution de l’application, ou d’une fonction de ladite application, dans le récepteur multimédia (2), entraîne la transmission sécurisée, depuis ledit récepteur et vers le module d’accès (3), d’au moins une desdites données d’authentification,
- l’authentification de l’application est basée sur une comparaison, dans le module d’accès (3), de la donnée d’authentification transmise par le récepteur multimédia (2), aux données d’authentification connues dudit module. - Procédé selon la revendication 2 comprenant les étapes suivantes :
- horodater, dans le module d’accès (3), les données d’authentification destinées à être transmises au récepteur multimédia (2) de manière à ce que lesdites données aient une période de validité limitée dans le temps,
- vérifier, dans le module d’accès (3), la période de validité de la donnée d’authentification transmise par le récepteur multimédia (2). - Procédé selon la revendication 1, comprenant les étapes suivantes :
- associer aux données d’application transmises au récepteur multimédia (2), une graine aléatoire adaptée pour initier un générateur de nombres pseudo-aléatoires (28) installé dans ledit récepteur, lequel générateur est basé sur un algorithme connu du module d’accès (3), laquelle association est réalisée dans ledit module d’accès,
- l’exécution de l’application, ou d’une fonction de ladite application, dans le récepteur multimédia (2), entraîne la transmission sécurisée, depuis ledit récepteur et vers le module d’accès (3), d’au moins un nombre pseudo-aléatoire généré par le générateur de nombres pseudo-aléatoires (28),
- l’authentification de l’application est basée sur une comparaison, dans le module d’accès (3), du nombre pseudo-aléatoire transmis par le récepteur multimédia (2), à l’algorithme connu dudit module. - Procédé selon l’une des revendications 1 à 4, comprenant les étapes suivantes :
- crypter le flux multimédia (1) avant de le diffuser dans un réseau de diffusion,
- traiter le flux multimédia crypté dans le module d’accès (3), lequel traitement consiste à :
-- décrypter le flux multimédia en fonction de droits d’accès enregistrés dans le module d’accès (3),
-- ajouter dans le flux multimédia décrypté, les données d’application,
-- chiffrer le flux multimédia contenant les données d’application,
- transmettre au travers de la connexion sécurisée (22, 32), depuis le module d’accès (3) et vers le récepteur multimédia (2), le flux multimédia traité (10),
- déchiffrer le flux multimédia traité dans le récepteur multimédia (2). - Procédé selon la revendication 5 prise en combinaison avec la revendication 2, consistant à continuer à traiter le flux multimédia (1) dans le module d’accès (3) et/ou continuer à transférer le flux multimédia traité (10) vers le récepteur multimédia (2), à la condition que la comparaison donne une correspondance entre la donnée d’authentification transmise par ledit récepteur et les données d’authentification connues dudit module.
- Procédé selon la revendication 5 prise en combinaison avec la revendication 3, consistant à continuer à traiter le flux multimédia (1) dans le module d’accès (3) et/ou continuer à transférer le flux multimédia traité (10) vers le récepteur multimédia (2), à la condition que la période de validité de la donnée d’authentification transmise depuis ledit récepteur ne soit pas échue.
- Procédé selon la revendication 5 prise en combinaison avec la revendication 4, consistant à continuer à traiter le flux multimédia (1) dans le module d’accès (3) et/ou continuer à transférer le flux multimédia traité (10) vers le récepteur multimédia (2), à la condition que la comparaison donne une correspondance entre le nombre pseudo-aléatoire transmis par ledit récepteur et l’algorithme connu dudit module.
- Procédé selon l’une des revendications 1 à 4, comprenant les étapes suivantes :
- crypter le flux multimédia (1) avant de le diffuser dans un réseau de diffusion,
- réceptionner, par le récepteur multimédia (2), le flux multimédia crypté,
- après vérification des droits d’accès par le module d’accès (3), transmettre de manière sécurisée, depuis ledit module d’accès et vers le récepteur multimédia (2), une ou plusieurs clés de décryptage (KEY) du flux multimédia crypté (1),
- décrypter, dans le récepteur multimédia (2), le flux multimédia avec la ou les clés de décryptage (KEY). - Procédé selon la revendication 9 prise en combinaison avec la revendication 2, consistant à cesser de transmettre la ou les clés de décryptage (KEY) au récepteur multimédia (2), si la comparaison ne donne pas une correspondance entre la donnée d’authentification transmise par ledit récepteur et les données d’authentification connues du module d’accès (3).
- Procédé selon la revendication 9 prise en combinaison avec la revendication 3, consistant à cesser de transmettre la ou les clés de décryptage (KEY) au récepteur multimédia (2), si la période de validité de la donnée d’authentification transmise depuis ledit récepteur est échue.
- Procédé selon la revendication 9 prise en combinaison avec la revendication 4, consistant à cesser de transmettre la ou les clés de décryptage (KEY) au récepteur multimédia (2), si la comparaison ne donne pas une correspondance entre le nombre pseudo-aléatoire transmis par ledit récepteur et l’algorithme connu du module d’accès (3).
- Procédé selon l’une des revendications 1 à 12, dans lequel les données d’application sont adaptées pour être installées dans le récepteur multimédia (2) sous la forme d’une application HbbTV.
- Procédé selon l’une des revendications 1 à 13, dans lequel le flux multimédia contient une vidéo et les données d’application intègrent une fonction de marquage de vidéo, ledit procédé comprenant les étapes consistant à :
- inclure des données de marquage de la vidéo dans les données d’application transmises au récepteur multimédia (2),
- réaliser le marquage de la vidéo en fonction des données de marquage, au moyen de la fonction de marquage de l’application exécutée dans le récepteur multimédia (2),
- le marquage de la vidéo dans le récepteur multimédia (2), entraîne la transmission sécurisée, depuis ledit récepteur et vers le module d’accès (3), de la donnée d’authentification. - Procédé selon l’une des revendications 1 à 13, dans lequel :
- les données d’application sont installées dans le récepteur numérique (2) sous la forme d’une application publicitaire ou d’une application forçant le visionnage d’une annonce publicitaire,
- si l’application est arrêtée volontairement avant la fin de son exécution :
-- le récepteur numérique (2) cesse de transmettre la donnée d’authentification au module d’accès (3), et
-- le module d’accès (3) effectue au moins l’une des action suivantes :
--- cessation d’un traitement du flux multimédia,
--- cessation d’un transfère du flux multimédia au récepteur numérique (2),
--- cessation d’une transmission, au récepteur numérique (2), d’une ou plusieurs clés de décryptage (KEY) du flux multimédia lorsque celui-ci est crypté,
--- limitation d’une transmission du flux multimédia au récepteur numérique (2), de sorte qu’une vidéo ou un programme contenu dans ledit flux s’affiche de manière limitée dans le temps, sur un écran (27) connecté audit récepteur. - Procédé selon l’une des revendications 1 à 15, comprenant les étapes consistant à :
- connecter le module d’accès (3) au récepteur multimédia (2) au moyen d’une connexion (22, 32, CS) sécurisée, les données d’application et la au moins une donnée d’authentification étant transmises au travers de cette connexion,
- sécuriser la connexion (22, 32, CS) en appliquant un chiffrement selon la norme DVB-CI+. - Système comportant un module d’accès (3) et un récepteur multimédia (2), configurés pour la mise en œuvre des étapes du procédé des revendications 1 à 16.
- Produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé selon la revendication 1, lorsqu'il est exécuté par un module d’accès (3) connecté à un récepteur multimédia (2).
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2004857A FR3110263A1 (fr) | 2020-05-15 | 2020-05-15 | Procédé et système pour authentifier une application informatique, ou une fonction de l’application, exécutée par un récepteur multimédia |
| PCT/FR2021/050834 WO2021229189A1 (fr) | 2020-05-15 | 2021-05-12 | Procédé et système pour authentifier une application informatique, ou une fonction de l'application,exécutée par un récepteur multimédia |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2004857A FR3110263A1 (fr) | 2020-05-15 | 2020-05-15 | Procédé et système pour authentifier une application informatique, ou une fonction de l’application, exécutée par un récepteur multimédia |
| FR2004857 | 2020-05-15 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR3110263A1 true FR3110263A1 (fr) | 2021-11-19 |
Family
ID=71784297
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR2004857A Pending FR3110263A1 (fr) | 2020-05-15 | 2020-05-15 | Procédé et système pour authentifier une application informatique, ou une fonction de l’application, exécutée par un récepteur multimédia |
Country Status (2)
| Country | Link |
|---|---|
| FR (1) | FR3110263A1 (fr) |
| WO (1) | WO2021229189A1 (fr) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20130232337A1 (en) * | 2012-03-02 | 2013-09-05 | Electronics And Telecommunications Research Institute | User terminal and method for playing digital rights management content |
| EP2797333A1 (fr) * | 2013-04-26 | 2014-10-29 | Nagravision S.A. | Procédé de filigranage de contenu de média et système pour mettre en 'uvre ce procédé |
| US20150172739A1 (en) * | 2012-08-21 | 2015-06-18 | Strategy And Technology Limited | Device authentication |
-
2020
- 2020-05-15 FR FR2004857A patent/FR3110263A1/fr active Pending
-
2021
- 2021-05-12 WO PCT/FR2021/050834 patent/WO2021229189A1/fr active Application Filing
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20130232337A1 (en) * | 2012-03-02 | 2013-09-05 | Electronics And Telecommunications Research Institute | User terminal and method for playing digital rights management content |
| US20150172739A1 (en) * | 2012-08-21 | 2015-06-18 | Strategy And Technology Limited | Device authentication |
| EP2797333A1 (fr) * | 2013-04-26 | 2014-10-29 | Nagravision S.A. | Procédé de filigranage de contenu de média et système pour mettre en 'uvre ce procédé |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2021229189A1 (fr) | 2021-11-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP2055102B1 (fr) | Procédé de transmission d'une donnée complémentaire a un terminal de réception | |
| 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 | |
| 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 | |
| FR2877119A1 (fr) | Procede et dispositif pour generer une cle de decryptage d'un contenu | |
| EP3236632B1 (fr) | Procede et dispositif permettant l'application d'un systeme de controle d'acces a la protection des flux video en mode direct | |
| EP2520042B1 (fr) | Procédés de déchiffrement, de transmission et de réception de mots de contrôle, support d'enregistrement et serveur pour ces procédés | |
| EP2567500B1 (fr) | Procedes de dechiffrement, de transmission et de reception de mots de controle, support d'enregistrement et serveur de mots de controle pour la mise en oeuvre de ces procedes | |
| EP2659613B1 (fr) | Procede de transmission et de reception d'un contenu multimedia | |
| EP2633677B1 (fr) | Procede de reception d'un contenu multimedia embrouille a l'aide de mots de controle et captcha | |
| EP3732849B1 (fr) | Procédé et système d'identification de terminal d'utilisateur pour la réception de contenus multimédia protégés et fournis en continu | |
| EP1419640B1 (fr) | Reseau numerique local, procedes d'installation de nouveaux dispositifs et procedes de diffusion et de reception de donnees dans un tel reseau | |
| WO2003073761A1 (fr) | Procede de traitement de donnees chiffrees pour un premier domaine et reçues dans un reseau appartenant a un second domaine | |
| WO2009112771A1 (fr) | Procédé d'affichage de contenus multimédia à perturbations variables en fonction de droits locaux de récepteurs/décodeurs | |
| EP2747444A1 (fr) | Procédé pour accéder à un service proposé par un serveur distant à l'aide d'un code QR | |
| FR3110263A1 (fr) | Procédé et système pour authentifier une application informatique, ou une fonction de l’application, exécutée par un récepteur multimédia | |
| EP1723791B1 (fr) | Methode de securisation d'un evenement telediffuse | |
| EP3646526B1 (fr) | Procédé de réception et de déchiffrement d'un cryptogramme d'un mot de contrôle | |
| FR3053497B1 (fr) | Procede de renforcement de la securite d'un systeme de television a peage a base de retro-communication periodique obligatoire | |
| EP2464134A1 (fr) | Inscription de droit avec activation locale | |
| WO2004032508A1 (fr) | Method pour la transmission securisee de fichiers audiovisuels | |
| EP2265013A1 (fr) | Transmission de contenu vers un équipement client comportant au moins un module de décodage et un module de sécurité | |
| WO2011086286A1 (fr) | Procédé de mise à jour d'un processeur de sécurité, système, programme d'ordinateur et processeur de sécurité correspondants |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20211119 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| RX | Complete rejection |
Effective date: 20230206 |