FR2876859A1 - Procede et installation de controle d'habilitation du logiciel interne d'un terminal recepteur - Google Patents

Procede et installation de controle d'habilitation du logiciel interne d'un terminal recepteur Download PDF

Info

Publication number
FR2876859A1
FR2876859A1 FR0411012A FR0411012A FR2876859A1 FR 2876859 A1 FR2876859 A1 FR 2876859A1 FR 0411012 A FR0411012 A FR 0411012A FR 0411012 A FR0411012 A FR 0411012A FR 2876859 A1 FR2876859 A1 FR 2876859A1
Authority
FR
France
Prior art keywords
terminal
server
software applications
download
control server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0411012A
Other languages
English (en)
Other versions
FR2876859B1 (fr
Inventor
Fabien Lloansi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Viaccess SAS
Original Assignee
Viaccess SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Viaccess SAS filed Critical Viaccess SAS
Priority to FR0411012A priority Critical patent/FR2876859B1/fr
Priority to EP05809248A priority patent/EP1803297A1/fr
Priority to PCT/FR2005/002495 priority patent/WO2006042932A1/fr
Priority to CN 200580035662 priority patent/CN101044758A/zh
Priority to TW094135672A priority patent/TW200627956A/zh
Publication of FR2876859A1 publication Critical patent/FR2876859A1/fr
Application granted granted Critical
Publication of FR2876859B1 publication Critical patent/FR2876859B1/fr
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/633—Control signals issued by server directed to the network components or client
    • H04N21/6332—Control signals issued by server directed to the network components or client directed to client
    • H04N21/6334—Control signals issued by server directed to the network components or client directed to client for authorisation, e.g. by transmitting a key
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
    • 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8166—Monomedia components thereof involving executable data, e.g. software
    • H04N21/818—OS software
    • 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8166—Monomedia components thereof involving executable data, e.g. software
    • H04N21/8193—Monomedia components thereof involving executable data, e.g. software dedicated tools, e.g. video decoder software or IPMP tool
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17345—Control of the passage of the selected programme

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Storage Device Security (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne le contrôle d'habilitation d'un terminal récepteur de télévision (4), qui communique avec un serveur (2) distant par une liaison bidirectionnelle (81-82), et reçoit par ailleurs un flux multimédia encodé. Dans l'invention, on stocke des informations d'habilitation du terminal auprès du serveur et auprès du terminal. Ainsi, à la mise sous tension du terminal, le terminal établit automatiquement une connexion vers le serveur, lequel récupère au moins une partie des informations d'habilitation stockées dans le terminal et vérifie une concordance avec les informations d'habilitation stockées auprès du serveur. En fonction de cette vérification, le serveur autorise ou non un téléchargement, vers le terminal, des applications logicielles pour le décodage du flux multimédia.

Description

Procédé et installation de contrôle d'habilitation du
logiciel interne d'un terminal récepteur L'invention concerne le contrôle d'habilitation du logiciel interne de terminaux récepteurs de flux multimédia à accès contrôlé, notamment de terminaux désembrouilleurs/décodeurs de télévision payante.
Dans les terminaux récepteurs de données multimédias, notamment de données de télévision payante, on prévoit habituellement un processeur de sécurité (tel qu'une carte à puce), intégré dans le récepteur ou connecté à celui-ci. Ce processeur de sécurité contrôle l'accès aux données traitées par le récepteur, typiquement en autorisant ou interdisant le désembrouillage ou le décodage de ces données selon la conformité du récepteur à des critères d'accès attachés à ces données. Le processeur de sécurité permet en outre de vérifier l'habilitation du terminal récepteur à traiter les données, souvent en mettant en oeuvre une procédure d'authentification. Si le processeur de sécurité a bien vérifié que le terminal était habilité, il autorise l'exécution d'applications logicielles spécifiques permettant de désembrouiller/décoder le flux multimédia que reçoit le terminal. En revanche, si le terminal n'est pas habilité, le processeur de sécurité inhibe l'exécution des applications logicielles précitées.
On indique que certains terminaux peuvent décoder les données multimédias (par exemple mener un décodage en compression de données audiovisuelles au format MPEG ou autre) à condition d'activer des fonctions internes de décodage. L'activation ou l'inhibition de ces fonctions de décodage sont conditionnées notamment par la vérification de la validité ou de l'invalidité, respectivement, des droits d'accès associés au terminal. Par ailleurs, des données multimédias telles que des données audiovisuelles peuvent être volontairement embrouillées, préalablement à la diffusion. Les fonctions de désembrouillage des données, auprès du terminal, peuvent être alors activées ou inhibées selon la vérification de la validité ou de l'invalidité des droits d'accès associés au terminal. Ci-après, on désignera indistinctement par les termes "désembrouillage" et/ou "décodage" les fonctions dont l'exécution ou l'inhibition sont conditionnées par la validité ou l'invalidité des droits d'accès.
Les terminaux, ainsi que les processeurs de sécurité qu'ils comportent, à disposition des usagers, ne se sont pas toujours avérés inviolables et des fraudes (notamment par falsification des codes d'authentification par des usagers malveillants) sont toujours possibles.
De plus, il est souvent difficile, pour les opérateurs fournisseurs de contenus, de contrôler le parc des terminaux à disposition des usagers, ainsi que les versions (autorisées ou, au contraire, pirates) des applications logicielles installées dans les terminaux.
Par ailleurs, avec le développement récent des applications multimédias interactives, notamment en contexte de télévision payante, nombreux sont aujourd'hui les terminaux équipés d'une voie de retour vers un ou plusieurs serveur(s) distant(s). Plus particulièrement, une liaison totalement bidirectionnelle entre serveur et terminal, par exemple de type xDSL (pour "Digital Subscriber Line"), s'est avérée avantageuse dans certaines applications récentes. Une telle liaison bidirectionnelle est à distinguer d'une simple voie de retour classique, par exemple de type RTC/IP.
La présente invention entend tirer parti de ces moyens de communication vers des serveurs distants, dont sont déjà équipés la plupart des terminaux récepteurs, pour résoudre substantiellement les problèmes rencontrés dans l'art antérieur et indiqués ci-avant.
A cet effet, elle propose d'abord un procédé de contrôle d'habilitation d'au moins un terminal récepteur d'un flux multimédia, dans lequel le terminal est agencé : d'une part, pour communiquer avec au moins un serveur distant par une liaison bidirectionnelle, et - d'autre part, pour recevoir un flux multimédia et désembrouiller/décoder ce flux par l'exécution d'applications logicielles spécifiques.
Au sens de l'invention, le serveur distant précité est un 25 serveur de contrôle de téléchargement des applications logicielles précitées vers le terminal.
Le procédé selon l'invention comporte alors les étapes suivantes.
a) on stocke des informations d'habilitation du terminal auprès du serveur de contrôle de téléchargement et auprès du terminal, b) à la mise sous tension du terminal, le terminal établit automatiquement une connexion vers le serveur de contrôle de téléchargement, c) le serveur de contrôle de téléchargement récupère au moins une partie des informations d'habilitation stockées auprès du terminal et vérifie une concordance avec les informations d'habilitation stockées auprès du serveur, et d) au moins en fonction de cette vérification faite par le serveur de contrôle de téléchargement, ce dernier autorise ou non un téléchargement vers le terminal des applications logicielles spécifiques pour le désembrouillage/décodage du flux multimédia.
Ainsi, on comprendra que l'autorisation de télécharger les applications logicielles de désembrouillage/décodage est donnée au niveau du serveur de contrôle de téléchargement, et non plus au niveau du terminal récepteur comme dans la technique de l'art antérieur.
La présente invention offre alors de nombreux avantages. 25 Elle offre déjà une possibilité d'évolution du contrôle d'habilitation dans la mesure où les conditions de téléchargement, basées sur les informations d'habilitation présentes dans le terminal, sont fixées par l'opérateur responsable du serveur précité. Ces conditions peuvent donc évoluer dans le temps selon le souhait de l'opérateur. Or, dans la technique de l'art antérieur, les conditions de téléchargement sont définies dans le terminal récepteur, et ne peuvent plus évoluer.
Ainsi, alors que le téléchargement d'une éventuelle nouvelle version des applications logicielles de désembrouillage/décodage était soumis, dans l'art antérieur, à des règles de sécurité qui dépendaient uniquement du terminal (notamment de son processeur de sécurité), ces règles de sécurité peuvent ne plus être figées pour chaque terminal et peuvent évoluer dans le temps, grâce à la mise en oeuvre du procédé selon l'invention. En effet, en déportant les fonctions d'habilitation vers un serveur de contrôle de téléchargement distant, dédié notamment au contrôle d'habilitation des terminaux, il suffit de mettre à jour ces règles de sécurité directement auprès de ce serveur, sans avoir à intervenir auprès des terminaux. On comprendra donc que l'opérateur responsable des contrôles d'habilitation effectués par le serveur de contrôle de téléchargement peut mettre à jour les applications logicielles et/ou les règles de sécurité en une seule intervention sur ce serveur.
Par ailleurs, l'étape de téléchargement des applications peut être mise à profit pour obtenir des informations sur les terminaux, telles que des statistiques sur leur configuration et leur utilisation. En effet, on comprendra que, par la mise en oeuvre du procédé selon l'invention, l'opérateur peut contrôler les téléchargements, notamment le nombre de téléchargements pour un même terminal, faire par exemple de la mesure d'audience, évaluer la migration des processeurs de sécurité (par exemple sous forme de cartes à puces) sur un parc de terminaux, ou autres.
Ainsi, dans un mode de réalisation avantageux, le serveur comporte une base de données stockant des informations d'habilitation de plusieurs terminaux et des applications logicielles spécifiques aux terminaux, en correspondance d'au moins des identifiants respectifs de terminaux, pour la gestion d'un parc de terminaux récepteurs à disposition d'usagers.
Pour assurer une mise à jour régulière des applications logicielles de désembrouillage/décodage auprès des terminaux, à l'étape d) , le serveur transmet préférentiellement au terminal une nouvelle version des applications logicielles la plus adaptée à ce terminal, le cas échéant. Par exemple, la version la plus adaptée peut être la version qui est disponible auprès du serveur et qui est la plus récente, selon la modernité du terminal.
Dans un mode de réalisation particulier, les applications logicielles comportent au moins un système d'exploitation (ou "Operating System" en vocable anglo-saxon) des ressources informatiques du terminal.
Avantageusement, les applications logicielles précitées comportent une application pour le désembrouillage/décodage du flux multimédia.
Dans un premier mode de réalisation, le terminal stocke, à l'étape d), les applications logicielles téléchargées du serveur dans une mémoire volatile, à chaque démarrage du terminal, typiquement lors d'une mise sous tension. De façon particulièrement avantageuse, aucune desdites applications n'est résidente dans le terminal. On contrôle ainsi, à partir du serveur de contrôle de téléchargement distant, toutes les applications logicielles de désembrouillage/décodage utilisées par les terminaux, avec un risque de fraude pratiquement nul.
Dans un second mode de réalisation, le terminal stocke les applications logicielles reçues du serveur de contrôle de téléchargement dans une mémoire permanente, typiquement dans une mémoire flash ou E2Prom. On comprendra ainsi que, dans ce mode de réalisation, le téléchargement des applications logicielles n'est pas systématique mais s'effectue de préférence pour une mise à jour des applications.
Avantageusement, dans ce second mode de réalisation, le serveur de contrôle de téléchargement peut vérifier en outre une cohérence avec le terminal de la version des applications logicielles qui est stockée dans la mémoire permanente du terminal. A cet effet, le serveur peut archiver, typiquement dans la base de données stockant les informations d'habilitation des terminaux, les versions qui devraient être installées auprès des différents terminaux. Préférentiellement, lors de sa première mise en service, un terminal se connecte au serveur de contrôle de téléchargement pour signifier audit serveur la version qu'il a en mémoire. Le serveur de contrôle de téléchargement archive alors une référence de la version enregistrée dans ce terminal, préférentiellement dans une base de données appropriée. Ensuite, pendant les connexions suivantes, le serveur de contrôle de téléchargement lit la version effectivement installée et la compare avec celle archivée dans sa base de données.
Ainsi, on comprendra que, avantageusement, le serveur de contrôle peut vérifier en outre une cohérence de la version des applications logicielles qui est stockée dans la mémoire permanente du terminal. En particulier, si la version installée diffère de celle archivée, le serveur de contrôle de téléchargement peut transmettre au terminal un ordre de blocage du terminal ou, le cas échéant, mettre à jour la version installée. En particulier, si une version plus appropriée doit remplacer celle stockée dans le terminal, le serveur de contrôle de téléchargement transmet avantageusement au terminal cette nouvelle version des applications logicielles.
Dans une réalisation préférée, les informations d'habilitation précitées comportent des données d'authentification. Dans cette réalisation, à l'étape c), le serveur de contrôle de téléchargement authentifie le terminal par une procédure mettant en oeuvre d'une part une clé publique fournie par le terminal et d'autre part une clé privée correspondante tirée des données stockées auprès du serveur.
Préférentiellement, le procédé prévoit une authentification mutuelle du serveur de contrôle de téléchargement et du terminal, par une procédure mettant en uvre, via la liaison bidirectionnelle, les clés publiques du terminal et du serveur et les clés privées respectives, tirées des données stockées auprès du serveur et du terminal.
A cet effet, le terminal comporte avantageusement un processeur de sécurité dans lequel on stocke initialement les données d'authentification du terminal vis-à-vis du serveur de contrôle de téléchargement. On peut prévoir typiquement une carte à puce, en tant que composant de sécurité, installée auprès du terminal, afin d'améliorer la sécurité du téléchargement. Avantageusement, on conserve ainsi, pour l'essentiel, la structure physique (hardware) classique des terminaux récepteurs existants et qui utilisent déjà ce type de processeurs de sécurité. Préférentiellement, on prévoit aussi un processeur de sécurité sensiblement homologue auprès du serveur de contrôle de téléchargement pour qu'il assure le contrôle d'habilitation.
Avantageusement, le procédé prévoit en outre une procédure de vérification d'intégrité des données d'applications logicielles transmises au terminal, avec, de préférence, une vérification d'authenticité de l'émetteur des données d'applications logicielles.
Avantageusement, on stocke initialement des programmes informatiques respectifs dans le terminal, d'une part, et auprès du serveur de contrôle de téléchargement, d'autre part, en mémoire permanente. Ces programmes permettent essentiellement: - d'établir d'abord une communication entre le serveur de 5 contrôle de téléchargement et le terminal, - vérifier, côté serveur de contrôle, l'habilitation du terminal, - et, côté terminal, télécharger éventuellement les applications logicielles précitées.
Ainsi, pour le terminal, on prévoit préférentiellement les étapes initiales suivantes: al) on équipe le terminal de ressources informatiques pour lire une routine de démarrage, a2) on prévoit une routine de démarrage incluant au moins une instruction de connexion du terminal vers le serveur, a3) et on stocke cette routine de démarrage dans une mémoire permanente du terminal.
A ce titre, la présente invention vise un produit programme informatique, destiné à être stocké dans une mémoire permanente d'un terminal récepteur, et comportant ainsi une routine de démarrage du terminal, pour la mise en oeuvre de tout ou partie des étapes du procédé selon l'invention.
Pour le serveur, on prévoit préférentiellement les étapes initiales suivantes.
a'l) on équipe le serveur de ressources informatiques pour lire une routine de téléchargement d'applications logicielles vers le terminal, a'2) on prévoit une routine de téléchargement incluant au 5 moins une instruction de vérification d'habilitation du terminal, a'3) et on stocke cette routine de téléchargement dans une mémoire permanente du serveur.
A ce titre, la présente invention vise aussi un produit programme informatique, destiné maintenant à être stocké dans une mémoire permanente d'un serveur de contrôle de téléchargement d'applications logicielles pour le désembrouillage/décodage d'un flux multimédia, et comportant ainsi une routine de contrôle de téléchargement d'applications logicielles, pour la mise en oeuvre de tout ou partie des étapes du procédé selon l'invention.
La présente invention s'applique avantageusement à la distribution de contenus multimédias, notamment de contenus de télévision payante, sur un réseau bidirectionnel à large bande (de l'anglais "broadband network"), permettant une délivrance de contenus allant au-delà de la simple diffusion de signaux de télévision sur un réseau mono-directionnel (ou "broadcast network" en vocable anglo-saxon).
A titre d'exemple non limitatif, la distribution précitée des contenus multimédias peut s'effectuer en mode "point à 30 point" (ou "peer-topeer").
A ce titre, la présente invention vise aussi une telle application du procédé au sens de l'invention.
La présente invention vise aussi un système de contrôle d'habilitation pour le téléchargement d'applications logicielles, notamment pour le désembrouillage/décodage d'un flux multimédia tel qu'un flux audiovisuel de télévision, comportant au moins: - un serveur de contrôle de téléchargement desdites 10 applications logicielles, et un terminal récepteur, d'une part relié au serveur de contrôle de téléchargement par une liaison bidirectionnelle pour télécharger lesdites applications logicielles, et agencé d'autre part pour recevoir le flux multimédia et désembrouiller/décoder ce flux par l'exécution des applications logicielles précitées.
Le terminal du système au sens de l'invention comporte des ressources informatiques pour: - stocker des premières informations d'habilitation du terminal, stocker et lire un programme informatique de démarrage comportant au moins une instruction de connexion automatique vers le serveur lors de la mise sous tension du terminal.
De son côté, le serveur de contrôle de téléchargement du système au sens de l'invention comporte des ressources informatiques pour: - stocker des secondes informations d'habilitation du terminal, - stocker et lire un programme informatique de téléchargement des applications logicielles comportant au moins: o une instruction de lecture des premières et 5 secondes informations d'habilitation, o un test de vérification de cohérence entre les premières et secondes informations d'habilitation, o et une instruction de téléchargement des applications logicielles, conditionnée au moins 10 par ledit test.
Dans la réalisation préférée où une authentification du terminal est menée, les premières et secondes informations d'habilitation comportent respectivement des premières et secondes données d'authentification. Le programme de démarrage du terminal comporte au moins une instruction pour former et communiquer au serveur des données d'authentification du terminal par une procédure mettant en oeuvre une clé publique tirée des premières données d'authentification. Le programme de téléchargement du serveur comporte au moins une instruction pour vérifier les données d'authentification du terminal par une procédure mettant en oeuvre une clé privée tirée des secondes données d'authentification. Le test précité peut comporter alors une instruction de vérification de cohérence entre la clé publique et la clé privée, à la manière d'une procédure classique d'authentification en cryptographie. On peut citer, à titre d'exemple aucunement limitatif, une procédure d'authentification utilisant l'algorithme de cryptographie dit "RSA" (pour "Rivest Shamir Adleman").
Dans le cadre d'une authentification mutuelle du terminal et du serveur, les programmes de démarrage du terminal et de téléchargement du serveur comportent avantageusement des instructions d'authentification homologues, avec échange et vérification de cohérence de données d'authentification obtenues par une procédure mettant en oeuvre des clés publiques transmises via la liaison bidirectionnelle et des clés privées respectives, tirées des premières et secondes données d'authentification.
Outre les caractéristiques préférentielles du procédé au sens de l'invention, propres au terminal récepteur et au serveur de contrôle de téléchargement, décrites ci-avant et que l'on peut retrouver avantageusement dans le système au sens de l'invention, la liaison bidirectionnelle entre le terminal et le serveur de contrôle de téléchargement est de préférence de type xDSL (pour "Digital Subscriber Line"). On comprendra néanmoins que la présente invention peut s'adapter à toute autre technologie de réseau bidirectionnel.
La présente invention vise aussi le terminal récepteur du système au sens de l'invention.
Elle vise aussi le serveur de contrôle de téléchargement et de contrôle d'habilitation du système au sens de l'invention.
D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée, donnée ci-après à titre d'exemple non limitatif, et des dessins annexés sur lesquels: - la figure 1 représente un exemple d'architecture du système au sens de l'invention, la figure 2a représente schématiquement les éléments d'un serveur de contrôle de téléchargement et de contrôle d'habilitation au sens de l'invention, - la figure 2b représente schématiquement la structure d'un terminal récepteur au sens de l'invention, - la figure 3 représente schématiquement la structure d'une mémoire flash du terminal, selon une réalisation particulière de l'invention, et - la figure 4 représente une réalisation préférée des différentes étapes menées par un procédé au sens de 15 l'invention.
On se réfère tout d'abord à la figure 1 pour décrire le système au sens de l'invention, dans l'architecture d'un réseau de télévision numérique, dans l'exemple représenté.
Le système comporte un réseau bidirectionnel 3 pour relier un terminal récepteur 4 à un serveur 2 de contrôle de téléchargement et de contrôle d'habilitation du terminal. Le terminal 4 et ce serveur 2 sont reliés par une liaison bidirectionnelle 81-82.
De manière générale, on indique que la présente invention offre le contrôle de la mise en marche d'un terminal récepteur de télévision numérique 4, ainsi que le téléchargement sécurisé et adapté auprès du terminal 4 d'une version d'applications logicielles notamment pour le désembrouillage/décodage. De préférence, à chaque démarrage, le terminal, relié au réseau 3 effectue une connexion vers le serveur de contrôle du téléchargement 2. Après une authentification mutuelle des deux entités 4 et 2, grâce aux processeurs de sécurité 5 et 6 dans l'exemple décrit, le serveur de contrôle 2 récupère des informations présentes sur le terminal 4 et sur le processeur de sécurité 6. Le serveur de contrôle 2 analyse ces informations et autorise ou non la poursuite du processus de démarrage. Les critères qui permettent de définir si un terminal récepteur est autorisé ou non à poursuivre la séquence de démarrage sont avantageusement modifiables auprès du serveur de contrôle 2 pour permettre une souplesse maximum.
En particulier, le serveur 2 peut autoriser ou non le téléchargement d'une version des applications logicielles vers le terminal récepteur. Le serveur 2 mémorise avantageusement toutes les informations afin d'effectuer des statistiques sur les terminaux récepteurs présents sur le réseau 3. La mise en marche complète du terminal permet ensuite d'accéder aux programmes de télévision diffusés par exemple par un autre serveur portant la référence 1 sur la figure 1, qui, lui, assure la distribution des contenus multimédias, avec, par exemple une diffusion des programmes audiovisuels de télévision.
En se référant à la figure 1, ce serveur de distribution multimédia 1 diffuse les programmes de télévision (flèche 7), via le réseau 3 dans l'exemple représenté. Ce serveur 1 est géré par l'opérateur qui diffuse les programmes.
Ce serveur 1 de distribution multimédia peut être distinct ou non du serveur 2 de contrôle de téléchargement au sens de l'invention.
On retiendra surtout que le serveur de contrôle 2 réalise le contrôle du terminal récepteur 4 et, plus particulièrement, le téléchargement éventuel des applications logicielles, de désembrouillage/décodage notamment. L'équipement 2 est donc appelé ci- après "serveur de contrôle de téléchargement". Ce serveur 2 est géré par l'opérateur et/ou le fournisseur du contrôle d'accès.
Bien qu'un seul terminal soit représenté sur la figure 1, on indique que le système au sens de l'invention peut inclure plusieurs terminaux 4, recevant le flux multimédia 7, contenant par exemple les données de télévision numérique à désembrouiller/décoder. De même, on peut prévoir aussi plusieurs serveurs de contrôle de téléchargement 2, ainsi que plusieurs serveurs 1 de diffusion des programmes, pour un même terminal à disposition d'un usager abonné à plusieurs services de télévision numérique.
On rappelle que tous les équipements de la figure 1 sont reliés par le réseau 3 préférentiellement par une liaison bidirectionnelle à haut débit, par exemple une liaison filaire telle qu'une liaison xDSL.
En se référant à la figure 2a, le serveur de contrôle de téléchargement 2 comporte: - un ou plusieurs processeurs de sécurité 5 pour assurer la sécurité de la connexion et du téléchargement vers le terminal, - une base de données 21 pour stocker notamment des données d'habilitation d'une pluralité de terminaux récepteurs 4, en correspondance d'identifiants respectifs, afin de gérer avantageusement tout un parc de terminaux à disposition d'usagers, - des moyens de traitement, tels qu'un processeur 22 pour mettre en oeuvre des instructions de programme informatique qui seront détaillées plus loin, et - de la mémoire 23 (permanente, par exemple de type ROM, et/ou de travail, par exemple de type RAM) pour le stockage et l'exécution des instructions de programme.
On indique simplement ici que le serveur de contrôle de téléchargement 2 comporte des ressources informatiques pour: - exécuter un programme mettant en oeuvre un algorithme de signature, qui assure l'authenticité de l'émetteur des applications logicielles (en l'espèce le serveur de contrôle 2) et aussi l'intégrité des données des applications logicielles signées et transmises, - de préférence, exécuter en outre un programme mettant en oeuvre un algorithme de calcul de CHECKSUM permettant, comme on le verra plus loin, de garantir encore l'intégrité des données des applications logicielles transmises, - exécuter en outre un programme mettant en oeuvre un 30 algorithme d'authentification, préférentiellement mutuelle, entre le serveur de contrôle 2 et le terminal récepteur 4, utilisant par exemple un algorithme de cryptographie mettant en oeuvre des clés publiques et clés privées, - stocker la version des applications logicielles qui est disponible pour un éventuel téléchargement et qui est la mieux adaptée pour différents terminaux ou types de terminaux 4, stocker, par exemple dans la base de données 21, une liste noire des identifiants uniques des processeurs de sécurité non autorisés (correspondant par exemple à des cartes à puce volées ou piratées), et stocker, par exemple dans la base de données 21, une liste noire des identifiants uniques des terminaux non autorisés (volés ou piratés par exemple).
Avantageusement, le serveur de contrôle de téléchargement 2 peut réaliser alors les actions suivantes: - la préparation d'une version d'applications logicielles à télécharger, avec un calcul du CHECKSUM sur l'application, le calcul d'une signature, etc, - la réception des connexions avec les terminaux, - la vérification de la configuration des terminaux (interdire par exemple, selon leur configuration, le fonctionnement d'un ou plusieurs terminaux), - éventuellement le téléchargement d'une nouvelle version logicielle sur les terminaux, - la mémorisation de toutes les connexions et toutes les informations reçues de chaque terminal, dans la base de données 21.
On rappelle que le calcul du CHECKSUM sur une application est une routine de garantie d'intégrité consistant par exemple à calculer la somme des octets qui composent cette application (somme dite aussi de "contrôle"), en particulier pour vérifier l'intégrité d'un fichier ou d'un bloc de données correspondant à ou utilisé dans cette application.
En se référant maintenant à la figure 2b, l'architecture 10 générale d'un terminal récepteur 4 de télévision numérique au sens de l'invention comporte: - des moyens de traitement tels qu'un processeur 14, relié par un bus 13 à des mémoires 15 à 18 (directement adressables par le processeur 14), - une mémoire morte, non volatile et non re-programmable,qui peut être de type ROM, portant la référence 15 sur la figure 2b et destinée typiquement à stocker un programme de démarrage du terminal, une mémoire vive, volatile, par exemple de type RAM, référencée 16 sur la figure 2b et destinée notamment à l'exécution des programmes et à la manipulation des données, en tant que mémoire de travail, - une mémoire permanente, non volatile, et re- programmable, par exemple de type flash 17 et/ou de 25 type E2PROM 18, contenant des paramètres de configuration et/ou de sécurité du terminal.
Comme indiqué ci-avant, les applications logicielles téléchargées du serveur de contrôle 2 peuvent être 30 stockées en mémoire vive 16, dans un premier mode de réalisation, ou en mémoire permanente 17 ou 18, dans un second mode de réalisation, comme on le verra plus loin.
On indique simplement ici que, dans le premier mode de réalisation, le téléchargement des applications logicielles de désembrouillage/décodage s'effectue à chaque démarrage (ou mise sous tension) du terminal. Le terminal exécute alors ces applications de désembrouillage/décodage depuis une mémoire volatile 16.
Dans le second mode de réalisation, le téléchargement s'effectue simplement à chaque disponibilité d'une nouvelle version appropriée des applications logicielles de désembrouillage/décodage. Le terminal exécute alors ces applications depuis la mémoire permanente 17 ou 18, par exemple à partir de la mémoire flash 17. On a représenté sur la figure 3 la structure d'une mémoire flash 17, selon ce second mode de réalisation dans lequel on prévoit un téléchargement en mémoire permanente. La mémoire flash 17 comporte une partie 171 non réinscriptible (mémoire "OTP") pour stocker tout ou partie des instructions du programme de démarrage du terminal. La seconde partie 172 est une zone réinscriptible destinée typiquement au stockage des applications logicielles (APPL) téléchargées du serveur 2.
On indique que, dans une réalisation préférée, les applications logicielles qui peuvent être téléchargées incluent un système d'exploitation (ou "OS" pour "Operating System") chargé de gérer l'utilisation des ressources du terminal par ces applications. On comprendra ainsi l'importance de mettre à jour les versions de telles applications logicielles auprès des terminaux récepteurs. Ainsi, en se référant à nouveau à l'exemple de la figure 3, la dernière version du système d'exploitation OS (UPD) est préférentiellement stockée dans la zone réinscriptible 172 de la mémoire flash 17.
Par ailleurs, le programme de démarrage peut être stocké en mémoire ROM 15 et/ou en mémoire permanente 17 ou 18. Ce programme de démarrage (ou "boot" en vocable anglo-saxon) assure: - l'initialisation du terminal 4, - et, éventuellement, le téléchargement d'une nouvelle version des applications logicielles de désembrouillage/décodage.
Ce programme de démarrage comporte avantageusement: - les pilotes (ou "drivers") minimaux permettant de contrôler les seuls composants hardware (processeur, mémoires, interface avec le processeur de sécurité, ou autres) nécessaires à la connexion, au contrôle d'habilitation et au téléchargement, - une configuration de connexion (paramétrée en fonction de paramètres principaux pour se connecter sur le serveur de contrôle de téléchargement 2, ainsi que des paramètres de repli permettant une connexion vers d'autres serveurs de contrôle en cas d'échec de la communication avec le serveur 2), - un programme mettant en oeuvre un algorithme par exemple de cryptographie utilisant une clé privée du terminal, 30 et le cas échéant une clé publique du serveur, pour contribuer à l'authentification du terminal par le serveur ou procéder à l'authentification mutuelle du terminal et du serveur, - un algorithme asymétrique mettant en oeuvre une clé privée, ici pour vérifier la signature de la version des applications logicielles téléchargées, et, de là, l'intégrité des données téléchargées, ainsi que l'authenticité de l'émetteur desdites données, et - un algorithme de vérification (CHECKSUM) pour contrôler encore l'intégrité des applications téléchargées.
La mémoire morte du terminal stocke aussi un identifiant unique du terminal, appelé par exemple "STB-id" dans le cas où le terminal récepteur est un terminal désembrouilleur/décodeur d'un flux audiovisuel de type "STB" (pour "Set Top Box"). On indique toutefois qu'en variante, le terminal récepteur peut consister en un ordinateur de salon ou en un ordinateur portable, auxquels sont attribués des identifiants respectifs uniques.
Le terminal 4 comporte en outre: - une interface 10 avec le réseau 3 (par exemple une interface modem xDSL) permettant notamment l'échange de données avec les serveurs 1 et 2, - un démultiplexeur/désembrouilleur 11 assurant les fonctions de séparation des données (audio, vidéo, données d'interaction, données privées, et autres), un décodeur-convertisseur numérique/analogique 12, audio et vidéo, et - un processeur de sécurité 6 tel qu'une carte à puce 30 pour assurer la sécurité de la connexion vers le serveur 2 et la sécurité du téléchargement des applications.
Le processeur de sécurité 6 est connecté au terminal 4 par 5 un module d'entrée/sortie 19.
On indique en outre que l'usager du terminal peut agir sur les fonctions du terminal via une interface homme/machine 20 reliée au module 19 précité. L'interface 20 peut comporter par exemple une télécommande et un affichage de données sur l'écran de télévision.
Par ailleurs, chaque processeur de sécurité 6 comporte: - des ressources informatiques pour exécuter un algorithme asymétrique mettant en oeuvre au moins une clé privée et au moins une clé publique permettant de réaliser une authentification mutuelle du terminal et du serveur 2, - des ressources informatiques pour mettre en oeuvre une routine pour lire et transmettre, notamment au serveur 2 lorsqu'il s'agit du processeur de sécurité 6 relié au terminal, un identifiant unique de processeur de sécurité noté UA (pour "Unique Address"), - une mémoire non volatile re-programmable permettant de stocker des informations telles qu'un code confidentiel, des droits d'accès aux programmes, ou autres.
On se réfère maintenant à la figure 4 pour décrire les 30 étapes de vérification et de téléchargement éventuel dans un exemple de réalisation du procédé au sens de l'invention.
On a représenté sur la figure 4, côté gauche, les étapes 5 menées par le terminal 4 et, côté droit, les étapes menées par le serveur de contrôle de téléchargement 2.
A chaque démarrage du terminal, le programme de démarrage prend la main, initialise les composants hardware et exécute une routine informatique au sens de l'invention qui se déroule préférentiellement comme suit.
A l'étape 30, ce programme commande le modem xDSL du terminal pour envoyer une demande de connexion vers le serveur de contrôle 2. Il utilise à cet effet les paramètres de connexion mémorisés, précités. A l'étape 31, le serveur de contrôle 2, s'il l'accepte, établit la connexion avec le terminal 4. A cette étape 31, le serveur de contrôle 2 peut avantageusement mémoriser l'heure et l'adresse du terminal. A l'étape 32, le programme teste si la connexion a réussi (flèche "ok") ou échoué (flèche "ko"). En cas d'échec de la connexion vers le serveur principal 2 ou vers les serveurs de repli comme indiqué ci-avant, le programme passe à l'étape de gestion des erreurs 52, décrite plus loin.
En cas de réussite de l'établissement de la connexion, à l'étape 33, le programme vérifie la présence du processeur de sécurité 6 par exemple en procédant à la réinitialisation (ou "RESET") de celui-ci. A l'étape 34, si le processeur de sécurité n'est pas présent (flèche ko), le programme passe à l'étape de gestion des erreurs 52. Sinon (flèche ok), il passe à l'étape suivante 35, correspondant à l'étape 36 mise en oeuvre par le serveur 2 et consistant à permettre l'authentification du terminal par le serveur ou à vérifier leur authentification mutuelle avec l'aide du processeur de sécurité 6 du terminal 4 et du processeur de sécurité 5 du serveur de contrôle 2. Comme indiqué ci-avant, cette authentification peut être menée par une utilisation de clés publiques et de clés privées respectives.
Si cette étape d'authentification a échoué (au test 37), le programme passe à l'étape 52. Par ailleurs, en cas d'échec du test homologue d'authentification 38 mené auprès du serveur de contrôle 2, le serveur 2 mémorise le résultat négatif de l'authentification à l'étape 49.
En revanche, si l'étape d'authentification est passée avec succès, le terminal récupère et transmet au serveur 2, à l'étape 39, les informations relatives à, et non exhaustivement: l'adresse physique du terminal, l'identifiant unique du processeur de sécurité, - l'identifiant unique du terminal (par exemple de type STB-id), - le cas échéant, dans le second mode de réalisation précité, la version courante des applications logicielles stockées en mémoire permanente 17 ou 18, - d'autres données significatives présentes sur le processeur de sécurité 6 (droits d'accès aux programmes, code d'accès confidentiel, ou autres), - et les informations de configuration ou de sécurité contenues en mémoire permanente 17 ou 18.
Ainsi, on comprendra, en termes généraux, que l'on affecte initialement au terminal 4 et/ou au processeur de sécurité 6 des identifiants respectifs qui, avantageusement peuvent être stockés auprès du terminal 4 et auprès du serveur 2, en tant qu'informations d'habilitation du terminal équipé de son processeur de sécurité 6. Ainsi, au cours de la connexion entre le serveur et le terminal, ce dernier peut s'identifier auprès du serveur en transmettant ces identifiants au serveur.
De son côté, le serveur de contrôle 2 récupère, à l'étape 40, les informations que lui transmet le terminal et les mémorise. Selon l'un des avantages que procure la présente invention, le serveur peut alors mener des statistiques sur chaque terminal, incluant par exemple le nombre total de téléchargements depuis sa mise en service, le nombre moyen de démarrages de terminal par jour, le nombre de processeurs de sécurité utilisés par un terminal, ou autres.
A l'étape 41, le serveur de contrôle 2 vérifie que les 25 informations reçues sont cohérentes. En particulier, et non exhaustivement: l'identifiant unique du processeur de sécurité ne doit pas être en liste noire, - l'identifiant unique du terminal ne doit pas être en 30 liste noire, - l'identifiant unique du processeur de sécurité et l'identifiant unique du terminal vont de paire, les droits d'accès tirés du processeur de sécurité sont cohérents, - les autres informations de sécurité sont cohérentes, - la version des applications logicielles stockée en mémoire permanente dans le terminal, dans le second mode de réalisation précité, doit être cohérente avec les données dans la base du serveur de contrôle 2.
On rappelle que les critères qui permettent de définir si un terminal récepteur est autorisé ou non à poursuivre la séquence de démarrage sont avantageusement modifiables dans le serveur de contrôle même, pour assurer une souplesse maximum.
Si les informations ne sont pas cohérentes, le serveur de contrôle 2 passe à l'étape de mémorisation des erreurs 49, puis à l'état de déconnexion avec anomalie "DECONNECT KO" portant la référence 50.
En revanche, si les informations sont cohérentes: - dans le premier mode de réalisation (applications stockées en mémoire vive), le serveur 2 effectue le téléchargement dans le terminal de la version la mieux adaptée au terminal (étapes 44 et 45) ; on comprendra que dans ce premier mode, les étapes 42 et 43 ne sont pas exécutées car le téléchargement est à faire systématiquement, - dans le second mode de réalisation de l'invention (applications stockées en mémoire permanente), à l'étape 42, le serveur de contrôle 2 vérifie s'il doit télécharger une nouvelle version des applications logicielles, par exemple par comparaison d'un numéro de version reçu avec un numéro de version des applications logicielles disponibles sur le serveur 2.
Dans ce second mode, si aucun téléchargement n'est à effectuer, le serveur 2 informe le terminal 4 qu'aucun téléchargement n'est à effectuer (étape 43) et passe à l'étape de déconnexion sans anomalie 60. De son côté, le terminal récepteur 4 passe aussi à l'étape 56 de déconnexion sans anomalie.
En revanche, dans ce second mode, si un téléchargement d'une version plus appropriée doit être effectué suite à l'étape 42, le serveur 2 informe le terminal (étape 43) du futur téléchargement de la nouvelle version et, à l'étape 45, le terminal reçoit cette nouvelle version.
On comprendra que les tests précités 42 et 43 sur la version préalablement installée auprès du terminal peuvent être supprimés dans le premier mode de réalisation avantageux où l'on stocke les applications logicielles en mémoire volatile.
Dans les deux modes de réalisation, le procédé se déroule ensuite par l'étape 44, dans laquelle le serveur de contrôle 2 envoie la version disponible et la mieux adaptée des applications logicielles au terminal, ainsi que la valeur du CHECKSUM et une signature numérique du fichier correspondant.
A l'étape 45, le terminal reçoit en mémoire vive 16 cette nouvelle version et, à l'étape 46, vérifie la signature numérique précitée à l'aide d'une clé privée prévue à cette fin et de l'algorithme asymétrique précité. A l'étape 47, si la signature n'est pas correcte, le terminal passe à l'étape d'erreurs 52. Sinon, à l'étape 48, le terminal vérifie la valeur du CHECKSUM par calcul du CHECKSUM puis par comparaison par rapport à la valeur envoyée. Au test 53, si la valeur du CHECKSUM n'est pas correcte, le terminal passe à l'étape 52. Sinon, le terminal sauvegarde les applications logicielles téléchargées en mémoire permanente 17, uniquement dans le second mode de réalisation précité, à l'étape 54 (représentée à cet effet en traits pointillés sur la figure 4).
A l'étape 55, le terminal 4 informe le serveur de contrôle 2 que l'opération de téléchargement s'est correctement déroulée et, à l'étape 56, il reçoit l'autorisation d'exécuter les applications logicielles. Ensuite, le terminal 4 et le serveur 2 peuvent passer à des étapes respectives 56 et 60 de déconnexion sans anomalie.
Finalement, le terminal peut ensuite mettre en uvre les applications logicielles permettant notamment le désembrouillage/décodage du flux multimédia reçu.
Toutefois, on précise qu'en cas d'erreur au niveau du 30 terminal ou en cas de réception (étape 51) de demande de déconnexion de la part du serveur de contrôle quand il identifie un cas d'erreur (étape 50), le terminal exécute préférentiellement l'étape 52 consistant à prévenir le serveur 2 d'une erreur et à afficher un message d'alarme, par exemple sur l'écran du poste de télévision de l'abonné, pour le prévenir. Le terminal se déconnecte ensuite du serveur (étape 57), puis se bloque (étape 58). L'utilisateur doit préférentiellement réinitialiser le terminal, dans ce cas.
En cas d'erreur détectée par le serveur 2 (typiquement une mauvaise authentification ou des paramètres du terminal qui sont incohérents), le serveur 2 passe à l'étape 49 consistant en une mémorisation des erreurs, suivie d'une étape 50 de déconnexion.
Bien entendu, la présente invention ne se limite pas à la forme de réalisation décrite ci-avant à titre d'exemple; elle s'étend à d'autres variantes.
Ainsi, on comprendra par exemple que la structure détaillée du terminal représentée sur la figure 2b est susceptible de variantes. De même, les étapes détaillées du procédé telles que représentées sur la figure 4 sont susceptibles de variantes. On a décrit ci-avant une mise en oeuvre avantageuse dans laquelle l'authentification était menée à partir des processeurs de sécurité précités, mais cette mise en oeuvre est encore susceptible de variantes, par exemple en prévoyant un module d'authentification directement incorporé dans le terminal.
Par ailleurs, dans une réalisation moins sophistiquée que celle décrite ci-avant à titre d'exemple, on peut prévoir une simple identification, sans authentification, du terminal connecté au serveur de contrôle, bien que cette réalisation soit actuellement préférée.

Claims (33)

Revendications
1. Procédé de contrôle d'habilitation d'au moins un terminal récepteur d'un flux multimédia, dans lequel le terminal (4) est agencé : - d'une part, pour communiquer avec au moins un serveur distant (2) par une liaison bidirectionnelle, et - d'autre part, pour recevoir un flux multimédia et décoder ce flux par l'exécution d'applications logicielles spécifiques, caractérisé en ce que ledit serveur est un serveur de contrôle (2) de téléchargement desdites applications logicielles, et en ce que le procédé comporte les étapes suivantes.
a) on stocke des informations d'habilitation du terminal auprès du serveur de contrôle et auprès du terminal, b) à la mise sous tension du terminal, le terminal établit automatiquement une connexion vers le serveur de contrôle, c) le serveur de contrôle récupère au moins une partie des informations d'habilitation stockées auprès du terminal et vérifie une concordance avec les informations d'habilitation stockées auprès du serveur, d) et, au moins en fonction de cette vérification, le serveur de contrôle autorise ou non un téléchargement, vers le terminal, des applications logicielles spécifiques pour le désembrouillage/décodage du flux multimédia.
2. Procédé selon la revendication 1, caractérisé en ce que les informations d'habilitation comportent des données d'authentification, et en ce que, à l'étape c), le serveur de contrôle authentifie le terminal par une procédure mettant en oeuvre, d'une part, une clé publique fournie par le terminal et, d'autre part, une clé privée correspondante tirée des données stockées auprès du serveur de contrôle.
3. Procédé selon la revendication 2, caractérisé en ce qu'il comporte une authentification mutuelle du serveur et du terminal, par une procédure mettant en oeuvre, via la liaison bidirectionnelle, les clés publiques du terminal et du serveur et les clés privées respectives, tirées des données stockées auprès du serveur et du terminal.
4. Procédé selon l'une des revendications 2 et 3, caractérisé en ce que le terminal comporte un processeur de sécurité (6) dans lequel on stocke initialement lesdites données d'authentification du terminal vis-à-vis du serveur de contrôle.
5. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'on affecte initialement au terminal un identifiant, stocké auprès du terminal et auprès du serveur, et en ce que, au cours de la connexion de l'étape b), le terminal s'identifie auprès du serveur en transmettant ledit identifiant au serveur.
6. Procédé selon la revendication 4, caractérisé en ce que l'on affecte un identifiant au processeur de sécurité, cet identifiant étant stocké auprès du terminal et auprès du serveur, et en ce que, au cours de la connexion de l'étape b), le terminal s'identifie auprès du serveur en transmettant au moins ledit identifiant du processeur de sécurité.
7. Procédé selon l'une des revendications précédentes, caractérisé en ce que le serveur comporte une base de données (21) stockant des informations d'habilitation de plusieurs terminaux et des applications logicielles spécifiques aux terminaux, en correspondance d'au moins des identifiants respectifs de terminaux, pour la gestion d'un parc de terminaux récepteurs à disposition d'usagers.
8. Procédé selon l'une des revendications précédentes, dans lequel les applications logicielles sont régulièrement mises à jour, caractérisé en ce que, à l'étape d), le serveur transmet au terminal une nouvelle version des applications logicielles la plus adaptée au terminal, le cas échéant.
9. Procédé selon l'une des revendications précédentes, caractérisé en ce que les applications logicielles comportent au moins un système d'exploitation (OS) de ressources informatiques du terminal.
10. Procédé selon l'une des revendications précédentes, caractérisé en ce que les applications logicielles comportent une application de désembrouillage/décodage du flux multimédia.
11. Procédé selon l'une des revendications précédentes, caractérisé en ce que, à l'étape d), le terminal stocke les applications logicielles téléchargées du serveur dans une mémoire permanente.
12. Procédé selon la revendication 11, prise en combinaison avec la revendication 8, caractérisé en ce que le serveur vérifie en outre une cohérence de la version des applications logicielles qui est stockée dans la mémoire permanente du terminal.
13. Procédé selon l'une des revendications 1 à 10, caractérisé en ce que, à l'étape d), le terminal stocke les applications logicielles téléchargées du serveur dans une mémoire volatile (16), à chaque mise sous tension du terminal.
14. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comporte une procédure de vérification d'intégrité des données d'applications logicielles transmises au terminal, avec, de préférence, une vérification d'authenticité de l'émetteur desdites données d'applications logicielles.
15. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comporte les étapes initiales 30 suivantes: a1) on équipe le terminal de ressources informatiques pour lire une routine de démarrage, a2) on prévoit une routine de démarrage incluant au moins une instruction de connexion du terminal vers le 5 serveur, a3) et on stocke ladite routine de démarrage dans une mémoire permanente du terminal.
16. Procédé selon l'une des revendications précédentes, 10 caractérisé en ce qu'il comporte les étapes initiales suivantes.
ail) on équipe le serveur de contrôle de ressources informatiques pour lire une routine de téléchargement d'applications logicielles vers le terminal, a'2) on prévoit une routine de téléchargement incluant au moins une instruction de vérification d'habilitation du terminal, a'3) et on stocke ladite routine de téléchargement dans une mémoire permanente du serveur.
17. Produit programme informatique, destiné à être stocké dans une mémoire permanente (15) d'un terminal récepteur, caractérisé en ce qu'il comporte une routine de démarrage du terminal, pour la mise en oeuvre de tout ou partie des étapes du procédé selon la revendication 15.
18. Produit programme informatique, destiné à être stocké dans une mémoire permanente d'un serveur de contrôle de téléchargement d'applications logicielles pour le désembrouillage/décodage d'un flux multimédia, caractérisé en ce qu'il comporte une routine de contrôle de téléchargement d'applications logicielles, pour la mise en uvre de tout ou partie des étapes du procédé selon la revendication 16.
19. Application du procédé selon l'une des revendications 1 à 16 à la distribution de contenus multimédias, notamment de contenus de télévision payante.
20. Système de contrôle d'habilitation pour le téléchargement d'applications logicielles, notamment pour le désembrouillage/décodage d'un flux multimédia, caractérisé en ce qu'il comporte au moins: un serveur (2) de contrôle de téléchargement desdites applications logicielles, et - un terminal récepteur (4), d'une part relié au serveur de contrôle par une liaison bidirectionnelle (81-82) pour télécharger lesdites applications logicielles, et agencé d'autre part pour recevoir le flux multimédia embrouillé/encodé et désembrouiller/décoder ce flux par l'exécution desdites applications logicielles, en ce que le terminal comporte des ressources informatiques pour: stocker des premières informations d'habilitation du terminal, - stocker et lire un programme informatique de démarrage comportant au moins une instruction de connexion automatique vers le serveur lors de la mise sous tension du terminal, et en ce que le serveur de contrôle comporte des ressources informatiques pour: - stocker des secondes informations d'habilitation du terminal, stocker et lire un programme informatique de téléchargement des applications logicielles comportant au moins.
o une instruction de lecture des premières et secondes informations d'habilitation, o un test de vérification de cohérence entre les premières et secondes informations d'habilitation, o et une instruction de téléchargement des applications logicielles, conditionnée au moins par ledit test.
21. Système selon la revendication 20, caractérisé en ce que les premières et secondes informations d'habilitation comportent respectivement des premières et secondes données d'authentification, en ce que le programme de démarrage comporte au moins une instruction pour former et communiquer au serveur une clé publique tirée des premières données, et en ce que le programme de téléchargement comporte au moins une instruction pour former une clé privée tirée des secondes données, tandis que ledit test comporte une instruction de vérification de cohérence entre la clé publique et la clé privée.
22. Système selon la revendication 21, caractérisé en ce que les programmes de démarrage et de téléchargement comportent des instructions d'authentification homologues pour mener des authentifications mutuelles du serveur et du terminal, avec échange de clés publiques transmises via la liaison bidirectionnelle et vérifications de cohérence avec des clés privées respectives, tirées des premières et secondes données d'authentification.
23. Système selon l'une des revendications 21 et 22, caractérisé en ce que le terminal comporte un processeur de sécurité (6) stockant au moins lesdites premières données d'authentification.
24. Système selon l'une des revendications 20 à 23, caractérisé en ce que lesdites premières et secondes informations d'habilitation comportent un identifiant de terminal.
25. Système selon les revendications 23 et 24, caractérisé en ce que lesdites premières et secondes informations d'habilitation comportent en outre un identifiant de processeur de sécurité.
26. Système selon l'une des revendications 24 et 25, caractérisé en ce que le serveur comporte une base de données (21) stockant des informations d'habilitation de plusieurs terminaux et des applications logicielles spécifiques aux terminaux, en correspondance d'au moins des identifiants respectifs de terminaux, pour la gestion d'un parc de terminaux récepteurs à disposition d'usagers.
27. Système selon l'une des revendications 20 à 26, caractérisé en ce que les applications logicielles comportent au moins un système d'exploitation de ressources informatiques du terminal.
28. Système selon l'une des revendications 20 à 27, caractérisé en ce que le terminal comporte une mémoire permanente pour stocker les applications logicielles issues du serveur.
29. Système selon la revendication 28, caractérisé en ce que ladite mémoire permanente est une mémoire flash (17) et/ou une mémoire E2PROM (18).
30. Système selon l'une des revendications 20 à 27, caractérisé en ce que le terminal comporte une mémoire volatile (16) pour stocker les applications logicielles issues du serveur.
31. Système selon l'une des revendications 20 à 30, caractérisé en ce que la liaison bidirectionnelle (81-82) entre le terminal et le serveur est de type xDSL.
32. Terminal récepteur, d'un système selon l'une des revendications 20 à 31.
33. Serveur d'un système selon l'une des revendications 20 à 31.
FR0411012A 2004-10-18 2004-10-18 Procede et installation de controle d'habilitation du logiciel interne d'un terminal recepteur Expired - Fee Related FR2876859B1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
FR0411012A FR2876859B1 (fr) 2004-10-18 2004-10-18 Procede et installation de controle d'habilitation du logiciel interne d'un terminal recepteur
EP05809248A EP1803297A1 (fr) 2004-10-18 2005-10-10 Procede et installation de controle d'habilitation du logiciel interne d'un terminal recepteur
PCT/FR2005/002495 WO2006042932A1 (fr) 2004-10-18 2005-10-10 Procede et installation de controle d'habilitation du logiciel interne d'un terminal recepteur
CN 200580035662 CN101044758A (zh) 2004-10-18 2005-10-10 控制接收器终端内部软件的启用的方法和装置
TW094135672A TW200627956A (en) 2004-10-18 2005-10-13 Method and installation for controlling enabling of the internal software of a receiver terminal

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0411012A FR2876859B1 (fr) 2004-10-18 2004-10-18 Procede et installation de controle d'habilitation du logiciel interne d'un terminal recepteur

Publications (2)

Publication Number Publication Date
FR2876859A1 true FR2876859A1 (fr) 2006-04-21
FR2876859B1 FR2876859B1 (fr) 2007-01-05

Family

ID=34950904

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0411012A Expired - Fee Related FR2876859B1 (fr) 2004-10-18 2004-10-18 Procede et installation de controle d'habilitation du logiciel interne d'un terminal recepteur

Country Status (5)

Country Link
EP (1) EP1803297A1 (fr)
CN (1) CN101044758A (fr)
FR (1) FR2876859B1 (fr)
TW (1) TW200627956A (fr)
WO (1) WO2006042932A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008127092A3 (fr) * 2007-03-14 2009-02-19 Aht Europ Ltd Dispositif et procédé pour obtenir un accès conditionnel à un réseau de données
EP1857956A3 (fr) * 2006-05-09 2010-04-07 Apple Inc. Détermination de la validité de l'abonnement pour l'utilisation d'un contenu numérique

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101795295A (zh) * 2010-03-11 2010-08-04 北京安天电子设备有限公司 一种基于点对点技术的局域网病毒库升级系统和方法
CN102347939B (zh) 2010-08-05 2015-09-09 华为终端有限公司 软件管理的方法、装置及系统
CN102647282B (zh) * 2011-02-18 2015-06-17 鸿富锦精密工业（深圳）有限公司 基于poe对网络装置进行管理的电子装置及方法
JP2012221240A (ja) * 2011-04-08 2012-11-12 Sony Corp 情報処理装置、認証方法及びプログラム
CN103024438B (zh) * 2012-12-31 2016-06-08 深圳市九洲电器有限公司 一种机顶盒及其生产测试方法、系统
CN105635094B (zh) * 2015-06-16 2019-04-12 宇龙计算机通信科技(深圳)有限公司 安全验证方法、安全验证装置和安全验证系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003053055A1 (fr) * 2001-12-18 2003-06-26 Thomson Licensing S.A. Sous-titrage/teletexte code genere de maniere interne et destine a des menus de reglage d'appareil de traitement de signal pouvant etre mis en reseau
US20040025013A1 (en) * 2002-07-30 2004-02-05 Imagictv Inc. Secure multicast flow

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003053055A1 (fr) * 2001-12-18 2003-06-26 Thomson Licensing S.A. Sous-titrage/teletexte code genere de maniere interne et destine a des menus de reglage d'appareil de traitement de signal pouvant etre mis en reseau
US20040025013A1 (en) * 2002-07-30 2004-02-05 Imagictv Inc. Secure multicast flow

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1857956A3 (fr) * 2006-05-09 2010-04-07 Apple Inc. Détermination de la validité de l'abonnement pour l'utilisation d'un contenu numérique
EP3093782A1 (fr) * 2006-05-09 2016-11-16 Apple Inc. Détermination de la validité de l'abonnement pour l'utilisation d'un contenu numérique
US10528705B2 (en) 2006-05-09 2020-01-07 Apple Inc. Determining validity of subscription to use digital content
WO2008127092A3 (fr) * 2007-03-14 2009-02-19 Aht Europ Ltd Dispositif et procédé pour obtenir un accès conditionnel à un réseau de données

Also Published As

Publication number Publication date
CN101044758A (zh) 2007-09-26
TW200627956A (en) 2006-08-01
WO2006042932A1 (fr) 2006-04-27
EP1803297A1 (fr) 2007-07-04
FR2876859B1 (fr) 2007-01-05

Similar Documents

Publication Publication Date Title
EP1683388B1 (fr) Methode de gestion de la sécurité d'applications avec un module de sécurité
EP2177025B1 (fr) Procédé et dispositif de chiffrement partiel d'un contenu numérique
EP1815681A2 (fr) Unité de traitement de données audio/vidéo numériques et méthode de contrôle d'accès audites données
FR3025377A1 (fr) Gestion de tickets electroniques
EP1454489A1 (fr) Protocole de controle du mode d acces a des donnees transmises en mode point a point ou point multi-point
EP1603088A1 (fr) Composant pour module de sécurité
EP1353511A2 (fr) Procédé de gestion de droits d'accès à des services de télévision
FR2848764A1 (fr) Procede de controle d'acces en television numerique payante
EP1994745B1 (fr) Procédé pour la distribution sécurisée de séquences audiovisuelles, décodeur et système pour la mise en uvre de ce procédé
EP1803297A1 (fr) Procede et installation de controle d'habilitation du logiciel interne d'un terminal recepteur
EP0820193B1 (fr) Procédé d'exploitation d'un appareil destiné à permettre l'accès à des services
WO2004017635A1 (fr) Méthode de vérification de la validité d'une clé pour un réseau domestique numérique
EP1946552A2 (fr) Méthode de sécurisation de données échangées entre un dispositif de traitement multimédia et un module de sécurité
FR2999851A1 (fr) Procede pour acceder a un service propose par un serveur distant.
EP1867159A2 (fr) Procede d'authentification d'un utilisateur d'un contenu numerique
FR2883683A1 (fr) Procede d'appariement entre un terminal et un processeur de securite, systeme et programme informatique pour la mise en oeuvre du procede
WO2004073307A1 (fr) Procede et systeme pour garantir l'integrite d'au moins un logiciel transmis a un module de chiffrement/dechiffrement et supports d'enregistrement pour mettre en oeuvre le procede
EP1010326A1 (fr) Procede et installation de telechargement d'une plateforme de decodeur d'usager
EP1723788B1 (fr) Procédé de gestion du traitement de données à accès conditionnel par au moins deux décodeurs
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
FR2865592A1 (fr) Procede de diffusion securisee de programmes de television, systeme de diffusion, decodeur et support de donnees correspondants.
WO2003077555A2 (fr) Protocole de commande a distance d'une action locale de generation d'un message d'ordre
WO2004071106A2 (fr) Méthode de stockage et de transmission d'informations générées par un module de sécurité
WO2005096628A1 (fr) Securisation d’un dispositif d’access a des bouquets de programmes de chaines encryptees
WO2008050055A2 (fr) Procede de gestion de droits d'acces a un contenu numerique dans un reseau de pairs

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20160630