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 œuvre 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 Une"), 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 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.

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 œuvre 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 œuvre 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 œuvre 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 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 œuvre de tout ou partie des étapes du procédé selon 1' invention.

Pour le serveur, on prévoit préférentiellement les étapes initiales suivantes :

a'I) 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 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 œuvre 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 à point" (ou "peer-to-peer") .

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 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 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.

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 œuvre 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 œuvre 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 œuvre 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 1'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 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 I) ₁ 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 œuvre 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 œuvre 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 œuvre 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 œuvre un 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 œuvre 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 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 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 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

5 002495

22

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 œuvre un algorithme par exemple de cryptographie utilisant une clé privée du terminal, 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 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 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é β 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 œuvre 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 étapes de vérification et de téléchargement éventuel dans

un exemple de réalisation du procédé au sens de 1' invention.

On a représenté sur la figure 4, côté gauche, les étapes 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 œuvre 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 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 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) , à

5 002495

29

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 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 œuvre avantageuse dans laquelle l' authentification était menée à partir des processeurs de sécurité précités, mais cette mise en . œuvre 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.