FR2930662A1 - Procede de securisation d'une scene evolutive, dispositif, signal et programme d'ordinateur correspondants, procede de mise a jour d'une scene evolutive, dispositif et programme d'ordinateur correspondants - Google Patents

Abstract

L'invention concerne un procédé de sécurisation d'une scène évolutive composée d'au moins un élément et destinée à être restituée sur un terminal.Selon l'invention, un tel procédé comprend les étapes suivantes :- création (10) d'au moins une règle de sécurisation, définissant au moins une autorisation de modification de ladite scène et/ou d'au moins un élément de ladite scène et/ou une autorisation d'exécution d'au moins une commande dans un contexte de restitution de ladite scène sur ledit terminal ;- attribution (10) d'une politique de sécurité, comprenant au moins une desdites règles de sécurisation, à ladite scène et/ou à au moins un desdits éléments de ladite scène.

Description

Procédé de sécurisation d'une scène évolutive, dispositif, signal et programme d'ordinateur correspondants, procédé de mise à jour d'une scène évolutive, dispositif et programme d'ordinateur correspondants. 1. Domaine de l'invention Le domaine de l'invention est celui de la restitution de scènes évolutives sur un terminal. Un tel terminal est par exemple un ordinateur de bureau, un ordinateur portable, un terminal de type radiotéléphone, un PDA (en anglais Personal Digital Assistant , en français assistant numérique personnel ), etc.

Plus précisément, l'invention concerne la sécurisation de telles scènes, notamment lorsqu'elles sont susceptibles d'être modifiées par une pluralité de sources. L'invention s'applique en particulier, mais de manière non limitative, aux contenus multimédia.

On entend notamment par contenu multimédia un ensemble composé d'au moins une scène graphique animée, ou à tout le moins susceptible d'évoluer au cours du temps, encore appelée scène multimédia, ou scène évolutive, et d'une série de commandes permettant de faire évoluer cette scène. Une scène évolutive correspond en particulier à l'agencement d'un 20 ensemble d'objets graphiques dans le temps et dans l'espace, avec lesquels l'utilisateur du terminal peut interagir. Notamment, l'invention s'applique aux formats de description de scènes graphiques déjà connus tels que le MPEG-4/LASeR (en anglais Lightweight Application Scene Representation , en français représentation applicative de 25 scènes légères ), MPEG-4/BIFS (en anglais Binary Format Scene , en français format binaire pour scène ), le SVG (en anglais Scalable Vector Graphics , en français graphiques vectoriels adaptables ), le SMIL (en anglais Synchronized Multimedia Integration Language , en français langage d'intégration multimédia synchronisés ), le XHTML (en anglais eXtensible HyperText Markup Language , en français langage de balisage hypertexte extensible ), etc. 2. Art antérieur Une scène évolutive peut être représentée sous la forme d'un arbre de 5 scène, dont les noeuds correspondent aux éléments de la scène. Un exemple de système de mise à jour de scène graphique est décrit dans le brevet français FR 2765983 déposé au nom de France TELECOM et TDF. Souvent, une seule source est apte à modifier une telle scène, et donc à modifier l'arbre de scène correspondant. 10 Cependant, notamment dans le cas des services mobiles, un arbre de scène peut être construit progressivement par application de scènes incrémentales successives à la scène d'origine, une scène incrémentale étant un ensemble de modifications d'une scène existante. Dans ce cas, plusieurs sources peuvent générer des instructions de modification d'un arbre de scène. 15 Les formats "Rich Media" ayant des commandes de mise à jour et permettant une telle définition incrémentale de scène sont actuellement : MPEG-4 BIFS , MPEG-4 LASeR , DIMS de l'organisation 3rd Generation Partnership Project (en anglais Dynamic and Interactive Multimedia Scenes , en français Scènes Multimédia Interactives et Dynamiques), RME de 20 l'organisation Open Mobile Alliance (en anglais Rich-Media Environment en français Environnement de Média Riche). Dans le cas où plusieurs sources sont susceptibles de modifier un arbre de scène, la question se pose de la confiance à accorder à ces sources multiples pour fournir une scène résultant de l'agrégation des contributions des différentes 25 sources. En effet, il existe une pluralité de types de modifications ou de mises à jour possibles pour une scène, par exemple : - un serveur envoie des commandes de mise à jour à exécuter à un instant donné ; 30 - des commandes de mise à jour ont été envoyées par un serveur, stockées dans le terminal de restitution de la scène puis leur exécution est déclenchée par une action de l'utilisateur du terminal ; - un serveur envoie des données qui, après traitement dans le terminal de restitution, résultent en l'application de commandes de mise à jour ; - un programme exécuté sur le terminal de restitution applique des commandes de mise à jour. Dans la plupart des cas, la mise à jour provient d'un serveur, même si elle peut être déclenchée par une action du terminal, ou construite par un programme sur le terminal (mais à partir de données issues d'un serveur).

Il est donc important de sécuriser ces mises à jour, et les accès à l'arbre de scène correspondants, quand ceux-ci ne sont pas mis en oeuvre par l'entité responsable de la conception du service, mais par une pluralité de sources. Dans le format SVG , une solution a été développée pour contourner ce problème de sécurisation d'une scène évolutive, avec l'utilisation d'un élément noté animation . Cet élément permet le chargement d'une seconde scène, contrôlée par la scène appelante, et ne permettant pas à la seconde scène d'interagir avec la première scène. Un inconvénient de cette technique de l'art antérieur est qu'elle ne résout pas le problème de sécurisation d'une scène évolutive pouvant être modifiée par plusieurs sources, mais l'évite en créant une seconde scène ne pouvant pas agir sur la première. Le format MPEG-4 BIFS propose également une solution permettant d'éviter les problèmes de sécurisation, avec la mise en oeuvre d'un élément noté Inline .

Il existe également, dans le domaine des applets Java le concept de SecurityManager . Ce concept englobe un ensemble de limitations sur les actions que peut invoquer un programme. Un inconvénient de cette solution de l'art antérieur réside dans l'aspect statique du SecurityManager , qui est par essence une classe Java, et ne peut donc pas permettre de spécifier par exemple à quels endroits une action peut être autorisée, ou à la demande de qui une action peut être autorisée. 3. Objectifs de l'invention L'invention a notamment pour objectif de pallier ces inconvénients de l'art antérieur. Plus précisément, un objectif de l'invention, selon au moins un mode de réalisation, est de permettre la sécurisation d'une scène évolutive susceptible d'être modifiée par une pluralité de sources. Notamment, l'invention a pour objectif de fournir une telle technique présentant de meilleures performances en termes d'intégrité d'une scène évolutive et en termes de multiplicité des modifications sécurisées possibles d'une scène évolutive. Un autre objectif de l'invention, selon au moins un mode de réalisation, est de fournir une telle technique assurant une compatibilité avec les scènes évolutives existantes et les terminaux existants de restitution de scènes. Un autre objectif de l'invention est de fournir une telle technique la plus flexible possible en termes de définition des données de sécurisation et des zones sécurisées dans une scène évolutive. 4. Exposé de l'invention L'invention propose une solution nouvelle qui ne présente pas l'ensemble de ces inconvénients de l'art antérieur, sous la forme d'un procédé de sécurisation d'une scène évolutive composée d'au moins un élément et destinée à être restituée sur un terminal. Selon l'invention, un tel procédé comprend les étapes suivantes : - création d'au moins une règle de sécurisation, définissant au moins une autorisation de modification de ladite scène et/ou d'au moins un élément de ladite scène et/ou une autorisation d'exécution d'au moins une commande dans un contexte de restitution de ladite scène sur ledit terminal ; - attribution d'une politique de sécurité, comprenant au moins une desdites règles de sécurisation, à ladite scène et/ou à au moins un desdits éléments de ladite scène. Ainsi, l'invention repose sur une approche nouvelle et inventive de la sécurisation d'une scène évolutive, en attribuant à un ou plusieurs éléments de la scène ou à la scène entière, une politique de sécurité, définissant les autorisations de modification associées à ce ou ces éléments ou à la scène entière, ainsi que les autorisations d'exécution d'une ou plusieurs commandes dans le contexte de restitution de la scène sur le terminal. Cette politique de sécurité est définie par des règles de sécurisation, 10 correspondant chacune à au moins une autorisation de modification ou d'exécution d'une commande. Par exemple, une règle de sécurisation peut spécifier qu'un type d'action (insertion, remplacement, effacement, exécution d'une commande, modification d'une règle de sécurisation ...) est autorisé sur l'élément, ou au contraire 15 qu'aucune action n'est autorisée sur l'élément, ou que seules des actions de modification sont autorisées... Ainsi, l'invention permet de sécuriser les évolutions d'une scène, en attribuant à certains, ou à tous les éléments de la scène, des autorisations de modification ou d'exécution d'une commande, permettant ensuite, par exemple 20 lors de la réception d'une mise à jour de la scène, de valider ou non la mise à jour en fonction des autorisations attribuées préalablement aux éléments de la scène. Selon un mode de réalisation de l'invention, la politique de sécurité est définie dans un fichier ou un flux distinct d'un fichier ou un flux de description de ladite scène évolutive. 25 Ainsi, le procédé selon l'invention permet de définir des politiques de sécurité associée à une scène, ou un élément d'une scène, sans modifier le fichier , ou le flux, de description de scène. Par exemple, une scène déjà créée, voire même déjà restituée et en cours d'utilisation, peut bénéficier d'une sécurisation selon l'invention. 30 Le procédé de sécurisation selon ce mode de réalisation de l'invention assure de cette façon une compatibilité avec des scènes déjà créées. De plus, le procédé selon ce mode de réalisation de l'invention permet également d'assurer une compatibilité avec les moteurs de rendu existants qui ne seraient pas aptes à utiliser les politiques de sécurité et à mettre en oeuvre une sécurisation de scène. En effet, les fichiers de description de scène n'étant pas modifiés, un moteur de rendu non adapté à gérer des politiques de sécurité peut traiter la scène évolutive et sa restitution comme une scène classique ne bénéficiant pas de politique de sécurité. Selon un autre mode de réalisation de l'invention, la politique de sécurité est définie dans un fichier ou un flux de description de ladite scène évolutive. Ainsi, le procédé selon ce mode de réalisation de l'invention permet de définir des politiques de sécurité associée à une scène, ou un élément d'une scène, directement dans le fichier ou le flux de description de scène, de façon à faciliter le traitement de ces politiques de sécurité. En effet, les règles de sécurisation sont directement accessibles à la lecture et au traitement de l'arbre de description de scène. De plus, cette variante permet des mises à jour des données de sécurisation avec les mêmes mécanismes que ceux utilisés pour les éléments de scène. Selon un aspect particulier de l'invention, le procédé de sécurisation comprend les étapes suivantes : - obtention d'au moins une information d'identification d'au moins une source apte à modifier ladite scène et/ou à modifier un contexte de restitution de ladite scène ; - association, dans ladite politique de sécurité, de ladite au moins une information d'identification à au moins une règle de sécurisation de ladite politique de sécurité. Ainsi, le procédé selon ce mode de réalisation de l'invention permet d'affecter des droits, correspondant aux autorisations attribuées aux éléments de la scène, à une ou plusieurs sources susceptibles d'être à l'origine de mises à jour de la scène, ou d'exécution de commandes dans un contexte de restitution de la scène.

Une source de mise à jour peut être à un serveur, par exemple un serveur transmettant des mises à jour de la scène. Une source peut également correspondre à un canal de communication, pouvant avoir pour fournisseurs de données un serveur ou une pluralité de serveurs. Par exemple, une source peut correspondre à une connexion de type http établie dans le contexte de restitution de la scène évolutive, entre le terminal de restitution de la scène, et un serveur distant, servant de noeud d'aiguillage, ou d'aiguilleur, pour des données en provenance d'une pluralité d'autres serveurs. Ainsi, le procédé selon l'invention permet de définir des droits associés à une connexion prédéfinie, ou à un canal de communication, et non aux fournisseurs de données utilisant la connexion ou le canal. Par exemple, une source de mise à jour peut avoir le droit de modifier un type d'éléments de la scène, quelque soit la modification, ou encore peut avoir le droit d'effectuer un type prédéfini d'action sur tous les éléments de la scène...

De cette manière, la politique de sécurité attribuée à un ou plusieurs éléments d'une scène peut être appliquée, par exemple lors d'une mise à jour demandée pour la scène, conjointement avec une vérification des droits de la source émettrice de la mise à jour. Ainsi, la sécurisation des évolutions de la scène est renforcée et 20 diversifiée. Une politique de sécurité peut donc être représentée sous la forme d'une liste de couples (information d'identification, règle de sécurisation). En particulier, les éléments d'une scène évolutive sont organisés selon une arborescence associant à au moins un élément père au moins un élément fils, et 25 une politique de sécurité attribuée audit élément père s'applique par défaut également audit au moins un élément fils. Ainsi, par défaut, un élément n'ayant pas de propre politique de sécurité bénéficie de la politique de sécurité attribuée à son élément père. Cela permet de ne pas avoir dans une scène d'éléments non sécurisés. 30 Selon un aspect particulier de l'invention, le procédé de sécurisation comprend une étape de définition d'au moins un groupe constitué d'éléments de ladite scène partageant une même politique de sécurité. Ainsi, il est possible d'attribuer une politique de sécurité à un (ou plusieurs) ensemble, ou groupe, d'éléments de la scène. De cette manière, une politique de sécurité peut être attribuée à différents niveaux de précision dans une scène : un élément, un groupe d'éléments ou la scène entière. Selon une caractéristique particulière de l'invention, lesdites modifications appartiennent au groupe comprenant au moins : - une insertion d'un élément dans ladite scène ; - une modification d'un élément dans ladite scène ; - une suppression d'un élément dans ladite scène ; - une modification d'un attribut dans ladite scène ; - une suppression d'un attribut dans ladite scène ; - une modification d'une politique de sécurité dans ladite scène.

Ainsi, ceci permet notamment de sécuriser les modifications impactant les éléments d'une scène, ou les attributs d'une scène, ainsi que les modifications impactant la politique de sécurité attribuée à un élément, un groupe d'éléments ou une scène entière. Par exemple, lesdites règles de sécurisation comprennent au moins une 20 information appartenant au groupe comprenant au moins : - une restriction d'application d'une modification à un élément de ladite scène ; - une restriction d'application d'une modification à un groupe d'éléments de ladite scène ; 25 - une restriction d'application d'une modification à tous les éléments d'un type prédéfini de ladite scène ; - une restriction d'application d'une modification à un type d'attributs de ladite scène ; - une restriction d'application d'une modification en fonction d'au moins un 30 critère prédéterminé ; - une restriction d'exécution d'une commande ou d'un groupe de commandes dans un contexte donné de ladite scène. Ainsi, les règles de sécurisation peuvent notamment spécifier le type de modification ou d'action autorisée, l'endroit dans la scène où l'action est autorisée (un élément, un groupe d'éléments, un type d'éléments ...), le type d'attributs sur lesquels l'action est autorisée... Par exemple, les règles de sécurisation peuvent être définies comme suit : - le droit de rester active en permanence pour une application ; - le droit d'afficher une icône/information(s) dynamique(s)/... au sein de l'interface graphique du terminal ; - le droit d'écouter une touche clavier pour changer de mode actif/inactif ; - le droit d'ajouter un élément dans un menu pour changer de mode actif/inactif ; - le droit de prendre le contrôle de l'écran en cas d'inactivité ; - le droit d'ajouter un message en superposition de l'application ; - le droit d'ajouter des éléments d'interface utilisateur ; - le droit de modifier un élément en fonction de son état (actif/inactif) ; - le droit d'ajouter un élément si d'autres éléments du même type n'existent pas déjà dans la scène ; - Selon un aspect particulier de l'invention, lesdites informations d'identification appartiennent au groupe comprenant au moins : - un identifiant ; - une adresse IP ; - un certificat utilisé pour signer un contenu transmis par ladite source. Ainsi, on peut mettre en oeuvre différents niveaux d'identification d'une source, en fonction du niveau de sécurité souhaité. Un simple identifiant ou une adresse IP n'assurent pas un niveau de sécurité très élevé, car ils peuvent être modifiés par la source pour correspondre à une source autorisée. En revanche, l'utilisation d'un certificat permet de garantir un certain niveau de sécurité en identifiant de manière plus sûre une source souhaitant modifier la scène. L'invention concerne également un procédé de mise à jour d'une scène évolutive créée le procédé de sécurisation décrit ci-dessus, ladite scène étant composée d'au moins un élément et destinée à être restituée sur un terminal.

Selon l'invention, un tel procédé comprend les étapes suivantes : - réception, en provenance d'une source et/ou d'un canal de transmission de données, d'une demande de mise à jour pour un élément de ladite scène évolutive, un groupe d'éléments de ladite scène évolutive, ou ladite scène évolutive entière et/ou d'une demande d'exécution d'une commande dans un contexte de restitution de ladite scène évolutive ; - acceptation ou refus de ladite demande de mise en jour et/ou demande d'exécution d'une commande, en fonction d'une politique de sécurité attribuée audit élément, ou audit groupe ou à ladite scène. Selon une caractéristique particulière de l'invention, le procédé de mise à jour comprend une étape d'identification de ladite source, délivrant une information d'identification, et l'étape d'acceptation tient compte d'une politique de sécurité associée à ladite information d'identification. Ainsi, il est possible de vérifier la validité d'une mise à jour reçue pour une scène, en tenant compte des politiques de sécurité définies au préalable dans la scène à mettre à jour, et de l'identification de la source à l'origine de la mise à jour. Par exemple, si le serveur ayant transmis la mise à jour n'est pas identifié dans les listes de couple (information d'identification, règle de sécurisation) des politiques de sécurité définies dans la scène, alors la mise à jour est refusée.

Si le serveur est connu, alors le procédé met en oeuvre des étapes supplémentaires pour valider ou non la mise à jour. Selon une caractéristique particulière de l'invention, ladite information d'identification est fournie par un moyen d'accès à ladite mise à jour et/ou ladite commande.

Ainsi, cette approche permet d'utiliser les moyens d'accès à la mise à jour (lecture d'un fichier, ouverture d'une connexion ...) pour en identifier la source et les droits associés. Par exemple, si une mise à jour est transmise via une connexion http, le moyen d'accès fournit directement l'identification de la source. Selon une autre caractéristique particulière de l'invention, ladite information d'identification est présente dans ladite mise à jour et/ou ladite commande. Ainsi, si les moyens d'accès à la mise à jour ne fournissent pas d'information d'identification de la source à l'origine de la mise à jour, par exemple dans le cas d'une ouverture et lecture de fichier, le procédé selon l'invention cherche l'information d'identification dans la mise à jour elle-même, par exemple sous la forme d'une signature ou d'un code. Notamment, ladite étape d'acceptation ou refus comprend les sous-étapes suivantes : - décodage de ladite mise à jour et/ou de ladite commande ; - identification d'une politique de sécurité associée audit élément ou audit groupe d'éléments ou à ladite scène concerné par ladite mise à jour ; - vérification de la présence d'une association de ladite information d'identification et d'au moins une règle de sécurisation correspondant à ladite mise à jour et/ou ladite commande décodée, dans ladite politique de sécurité identifiée, délivrant une décision d'acceptation de ladite mise à jour et/ou ladite commande si ladite vérification est positive. Ainsi, on peut s'assurer que la mise à jour demandée par le serveur identifié est effectivement autorisée. Dans un premier temps, le procédé décode la mise à jour afin de déterminer notamment à quelle partie de la scène elle s'applique (la scène entière, un groupe d'éléments, un élément ...), de quel type de mise à jour il s'agit (modification, exécution d'une commande, ...), ... Ensuite, à partir de ces informations, et notamment de l'information indiquant à quelle partie de la scène s'applique la mise à jour, le procédé identifie la politique de sécurité associée à la partie de la scène en question.

Enfin, le procédé vérifie que le type de mise à jour est bien autorisé sur la partie identifiée de la scène, par la source identifiée par l'information d'origine. Si tel est le cas, la mise à jour est validée, sinon, elle est refusée. L'invention concerne également un signal représentatif d'une scène évolutive composée d'au moins un élément et destinée à être restituée sur un terminal, comprenant au moins un champ de sécurisation comprenant au moins une information représentative d'une politique de sécurité, comprenant au moins une règle de sécurisation définissant au moins une autorisation de modification dudit élément et/ou de ladite scène, de façon à permettre ou interdire, dans un terminal, une modification requise par une source, en fonction de ladite politique. L'invention concerne encore un dispositif de sécurisation d'une scène évolutive composée d'au moins un élément et destinée à être restituée sur un terminal. Selon l'invention, un tel ledit dispositif comprend : - des moyens de création d'au moins une règle de sécurisation, définissant au moins une autorisation de modification de ladite scène et/ou d'au moins un élément de ladite scène et/ou une autorisation d'exécution d'au moins une commande dans un contexte de restitution de ladite scène sur ledit terminal ; - des moyens d'attribution d'une politique de sécurité, comprenant au moins une desdites règles de sécurisation, à ladite scène et/ou à au moins un desdits éléments de ladite scène. Un tel dispositif de sécurisation est notamment apte à mettre en oeuvre les étapes du procédé de sécurisation tel que décrit précédemment.

Un tel dispositif est par exemple un ordinateur ou un serveur utilisé pour la création de scènes évolutives. L'invention concerne aussi un dispositif de mise à jour d'une scène évolutive, ladite scène étant composée d'au moins un élément et destinée à être restituée sur un terminal.

Selon l'invention, un tel dispositif comprend : - des moyens de réception, en provenance d'une source et/ou d'un canal de transmission de données, d'une demande de mise à jour pour un élément de ladite scène évolutive, un groupe d'éléments de ladite scène évolutive, ou ladite scène évolutive entière et/ou d'une demande d'exécution d'une commande dans un contexte de restitution de ladite scène évolutive ; - des moyens d'acceptation ou refus de ladite demande de mise en jour et/ou demande d'exécution d'une commande, en fonction d'une politique de sécurité attribuée audit élément, ou audit groupe ou à ladite scène. Un tel dispositif de mise à jour est notamment apte à mettre en oeuvre les étapes du procédé de mise à jour tel que décrit précédemment. Un tel dispositif est par exemple un terminal de restitution de scènes évolutives. L'invention concerne encore un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, comprenant des instructions de code de programme pour la mise en oeuvre du procédé de sécurisation tel que décrit précédemment, lorsque ledit programme est exécuté sur un ordinateur. Enfin, l'invention concerne un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, comprenant des instructions de code de programme pour la mise en oeuvre du procédé de mise à jour tel que décrit précédemment, lorsque ledit programme est exécuté sur un ordinateur. 5. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : - la figure 1 présente les principales étapes du procédé de sécurisation selon un mode de réalisation particulier de l'invention ; - la figure 2 présente les principales étapes du procédé de mise à jour d'une scène créée selon le procédé illustré en figure 1 ; - la figure 3 présente les principales étapes des procédés de sécurisation et de mise à jour selon un mode de réalisation particulier de l'invention ; - les figures 4a et 4b illustrent un exemple de modification d'un arbre de scène selon l'art antérieur et selon un mode de réalisation particulier de l'invention. 6. Description d'un mode de réalisation de l'invention Le principe général de l'invention repose sur l'attribution d'une politique de sécurité à une scène évolutive, ou à un ou plusieurs de ses éléments, permettant de spécifier des autorisations de modifications pour la scène, ou pour un de ses éléments, en fonction de la ou des sources susceptibles de modifier la scène. L'approche de l'invention permet ainsi de sécuriser les évolutions d'une scène, notamment lorsque celle-ci est mise à jour par une ou plusieurs sources. La sécurisation d'une scène peut se poser dans les termes suivants : - certaines sources ont le droit de modifier la scène, et d'autres sources n'ont pas le droit : - certaines zones de la scène peuvent être modifiées et d'autres pas ; - certaines opérations sont autorisées sur certains éléments de la scène et d'autres pas ; - Ces exemples correspondent à des autorisations définies pour une scène, ou un ensemble de scènes. Ces autorisations peuvent également être combinées pour une sécurisation plus fine et précise. Par exemple, on peut autoriser une source à appliquer un type de 25 modifications sur un groupe d'éléments d'une scène. Ces principes sont décrits plus en détail ci-dessous, en relation avec les différentes figures illustrant des modes de réalisation de l'invention. On présente maintenant, en relation avec la figure 1, les principales étapes du procédé de sécurisation selon un mode de réalisation de l'invention.

On considère une scène évolutive à sécuriser, comprenant une pluralité d'éléments, pouvant être regroupés pour certains en groupes. On souhaite sécuriser cette scène pendant sa restitution sur un terminal, de façon à ne pas permettre des mises à jour non autorisées, ou des actions non autorisées dans le contexte de restitution de la scène sur le terminal, et garantir ainsi l'intégrité de la scène au cours de sa restitution et de ses évolutions. Lors d'une première étape 10, une ou plusieurs règles de sécurisation sont créées en relation avec la scène. Ces règles de sécurisation permettent de définir une ou plusieurs autorisations de modification applicables ensuite à la scène, ou à un élément de la scène ou encore à un groupe d'éléments de la scène. Ces règles de sécurisation permettent également de définir une ou plusieurs autorisations d'exécution de commandes dans un contexte de restitution de la scène sur le terminal. Par exemple, certaines mises à jour ne modifient pas la scène mais uniquement le contexte de restitution de la scène, par ajout d'une icône dans l'interface graphique du terminal par exemple, ou par modification du traitement de certaines touches du clavier du terminal de restitution de la scène. Une fois ces règles de sécurisation définies, une deuxième étape 11 du procédé consiste à les attribuer aux éléments de la scène (élément par élément, ou par groupe d'éléments, ou pour la scène entière), sous la forme d'une politique de sécurité. Ainsi, chaque élément de la scène est associé à une politique de sécurité, lui garantissant un contrôle sur les mises à jour qu'il peut subir. Une politique de sécurité peut comprendre une ou plusieurs règles de sécurité, selon le niveau de sécurité de l'élément auquel la politique est attribuée. Par exemple, une politique de sécurité générale peut être attribuée à la scène, autorisant le serveur de création de scène à toutes les mises à jour possibles, ainsi qu'à toutes les exécutions de commandes possibles. Ainsi, le serveur de création de la scène évolutive d'origine a tous les droits sur la scène et tous ses éléments.

Ensuite, une politique de sécurité peut être attribuée distinctement à chaque élément de la scène, pour préciser les actions autorisées sur chaque élément, ainsi que les sources autorisées à effectuer ces actions. Selon différentes variantes de réalisation, les politiques de sécurité peuvent être définies directement dans le fichier de description de la scène évolutive, ou dans un fichier distinct (ces deux variantes sont décrites plus en détails ci-dessous en relation avec les figures 4a et 4b). Des étapes supplémentaires du procédé de sécurisation selon l'invention sont décrites plus en détail en relation avec la figure 3, et notamment l'étape 30 permettant de définir une information d'identification de la pluralité de sources aptes à modifier la scène évolutive au cours de sa restitution. On décrit maintenant les principales étapes du procédé de mise à jour d'une scène évolutive comprenant notamment une ou plusieurs politiques de sécurité attribuées à un ou plusieurs des éléments de la scène, comme décrit ci- dessus. On considère que la scène évolutive est en cours de restitution sur un terminal, et qu'une source souhaite la mettre à jour. La première étape 20 consiste à recevoir une demande de mise à jour pour la scène, ou un élément ou groupe d'éléments de la scène, ou une requête d'exécution d'une commande dans le contexte de restitution de la scène. Par exemple, cette demande est émise par un serveur qui souhaite ajouter un élément dans la scène, à un endroit précis, ce qui correspond à ajouter un fils à un élément déjà présent dans l'arbre de scène. Ou encore, cette demande est émise par un serveur qui souhaite installer une application dans le contexte de restitution de la scène et ajouter en particulier l'icône de cette application dans la liste des applications disponibles sur le terminal. Une fois la demande reçue, celle-ci est acceptée ou refusée, lors d'une étape 21, en fonction d'une ou plusieurs politiques de sécurité attribuées à la scène, ou à un élément ou groupe d'éléments de la scène, en fonction de la cible de la mise à jour. Ainsi, avant d'accepter la mise à jour, ou la demande d'exécution d'une commande, on vérifie si cette mise à jour est autorisée, c'est-à-dire si la source émettrice est autorisée à modifier la scène et si la cible de la mise à jour (l'élément ou le groupe d'élément ou la scène entière) autorise la mise à jour en question. Cette étape d'acceptation ou de refus comprend plusieurs sous-étapes, décrites plus en détails en relation avec la figure 3, permettant notamment d'identifier la source et de vérifier si elle fait partie des sources autorisées à intervenir sur la scène, ou le contexte de restitution de la scène. On présente maintenant, en relation avec la figure 3, les principales étapes du procédé de sécurisation d'une scène évolutive et du procédé de mise à jour d'une telle scène, selon un mode de réalisation de l'invention. On considère, comme précédemment, une scène évolutive à sécuriser, 15 comprenant une pluralité d'éléments, pouvant être regroupés pour certains en groupes d'éléments. Les deux premières étapes 10 et 11 du procédé de sécurisation sont les mêmes que celles décrites précédemment, en relation avec la figure 1. L'étape suivante 30 consiste à identifier une pluralité de sources aptes à 20 modifier la scène évolutive concernée. Parmi ces sources, on peut par exemple définir un ou plusieurs serveurs, par une adresse IP, ou un certificat utilisé pour signer un contenu transmis par le serveur. On peut également identifier un canal de communication, ou une 25 connexion, servant à une pluralité de sources pour la transmission de mises à jour de la scène évolutive. Cette étape 30 délivre une ou plusieurs informations d'identification, qui sont ensuite associées, lors d'une étape 31, à une ou plusieurs règles de sécurisation, dans les politiques de sécurité attribuées aux éléments, ou groupes 30 d'éléments, de la scène.

Ainsi, une politique de sécurité correspond à une liste de couples (règles de sécurisation, informations d'identification). Par exemple, une politique de sécurité attribuée à un élément peut spécifier que seules deux sources identifiées S1 et S2 sont autorisées à modifier cet élément, mais non autorisées à le détruire. Ou encore, une politique de sécurité attribuée à un élément peut spécifier qu'une source S1 est autorisée à modifier et détruire l'élément, qu'une source S2 est autorisée à modifier l'élément sous certaines conditions (par exemple uniquement si l'élément n'a pas de fils), mais pas à le détruire, et qu'une source S3 n'a aucun droit de modification sur l'élément. La scène évolutive ainsi sécurisée est ensuite restituée sur un terminal, lors d'une étape 32. Au cours de cette restitution, la scène évolutive est amenée à être mise à jour, par une pluralité de sources, suite à des actions de l'utilisateur du terminal, ou à l'initiative des sources elles-mêmes, par exemple des serveurs. On considère dans ce mode de réalisation qu'une source S demande à mettre à jour la scène évolutive. Lors d'une étape 20 déjà décrite précédemment, la demande de mise à jour est reçue par le terminal de restitution.

L'étape suivante 33 consiste à identifier la source S à l'origine de la mise à jour, de façon à vérifier dans un premier temps que cette source S est autorisée à mettre à jour la scène. Cette étape d'identification de la source S délivre une information d'identification Is.

Cette information d'identification peut être obtenue de différentes façons, en fonction notamment du type d'accès, ou du moyen d'accès, à la mise à jour. En effet, lorsque le terminal reçoit une mise à jour, il est informé du moyen d'accès à cette mise à jour. Par exemple, la mise à jour peut être accessible par lecture d'un fichier, ou par ouverture d'une connexion, par exemple de type http , ou par accès à une adresse locale particulière sur le terminal.

Pour certains de ces différents moyens d'accès, l'identification de la source est fourni directement : par exemple, dans le cas de l'ouverture d'une connexion http , l'adresse de connexion http est précisée, identifiant ainsi la source.

Cependant, dans le cas par exemple où le moyen d'accès à la mise à jour correspond à la lecture d'un fichier, l'information d'identification n'est pas disponible directement et doit être récupérée dans le fichier lui-même. Dans ce cas, l'information d'identification est présente dans le contenu de la mise à jour, par exemple sous la forme d'un code ou d'une signature.

Une fois cette information d'identification Is obtenue, l'étape d'acceptation ou de refus 21 est mise en oeuvre. Cette étape comprend notamment les principales sous-étapes 34, 35 et 36. Au préalable, si l'information d'identification Is n'est présente dans aucune des politiques de sécurité attribuées à la scène (les politiques attribuées à la scène entière, et les politiques attribuées à des éléments ou groupes d'éléments de la scène), la mise à jour est directement refusée, car la source n'est pas autorisée à mettre à jour la scène, quelque soit la mise à jour et la cible de cette mise à jour. Si l'information Is est présente dans au moins une des politiques de sécurité attribuées à la scène, alors les sous-étapes suivantes sont mises en oeuvre. La sous-étape 34 consiste à décoder la mise à jour, notamment pour déterminer à quelle partie de la scène elle s'applique : la scène entière, un groupe d'éléments, un élément ... Cette étape de décodage permet également de connaître l'action ou les actions mises en oeuvre à l'exécution de la mise à jour (insertion d'un élément, suppression d'un élément, ...). On considère dans cet exemple que la mise à jour s'applique à un groupe d'éléments G, et qu'elle consiste à ajouter un fils à chacun des éléments du groupe G.

A partir de ce décodage de la mise à jour, la politique de sécurité P associée à ce groupe d'éléments G est identifiée, lors d'une étape 35, soit en lisant le fichier de description de la scène (lère variante décrite précédemment), soit en lisant le fichier distinct utilisé pour définir les politiques de sécurité de la scène (2ème variante décrite précédemment). L'étape 36 suivante vérifie si l'information d'identification Is est associée à une règle de sécurisation dans la politique de sécurité P du groupe d'éléments G auquel s'applique la mise à jour. Par exemple, si la politique de sécurité du groupe G spécifie entre autre que la source S (identifiée par Is) est autorisée à modifier le groupe, mais pas à le supprimer, alors la mise à jour est acceptée. Par contre, si la politique de sécurité du groupe G précise que la source S n'est pas autorisée à modifier le groupe, mais seulement un élément du groupe par exemple, alors la mise à jour est refusée. On présente maintenant, en relation avec les figures 4a et 4b, un arbre de scène auquel est appliquée une mise à jour respectivement selon l'art antérieur et selon un mode de réalisation de l'invention. Selon l'art antérieur, une mise à jour est appliquée à l'élément E sans sécurisation, c'est-à-dire sans vérification de l'origine de la source de la mise à jour, et sans application de règles d'autorisation de modifications dans la scène.

Quelque soit le type de mise à jour et la cible de la mise à jour, celle-ci est mise en oeuvre, avec le risque que la source à l'origine de la mise à jour ne soit pas une source reconnue et que la mise à jour dégrade la scène. Selon un mode de réalisation de l'invention, la même mise à jour est associée à des informations d'identification de la source et l'élément E, auquel est destinée la mise à jour, est associé à une politique de sécurité, telle que définie précédemment, permettant de vérifier si la mise à jour provenant de la source identifiée est autorisée sur l'élément E. Selon une première variante de ce mode de réalisation, la politique de sécurité associée à l'élément E est décrite dans le fichier de description de la scène. On peut donc représenter les données correspondant à cette politique de sécurité dans l'arbre de scène associé à la scène. De plus, ces données de politique de sécurité peuvent être traitées de la même manière que les autres données correspondant aux éléments de l'arbre de scène, et peuvent donc par exemple faire l'objet de mise à jour selon les mêmes mécanismes de mise à jour que les autres éléments de la scène. Ainsi, les données de politique de sécurité sont directement accessibles, pour traitement, à la lecture de l'arbre de scène. Selon une deuxième variante (non illustrée sur la figure 4b), la politique de 10 sécurité associée à l'élément E est décrite dans un fichier distinct du fichier de description de la scène. Ainsi, le format d'un fichier de description de scène est le même qu'une politique de sécurisation soit attribuée ou non à la scène. Par exemple, dans le cas d'une scène préexistante, il n'est pas nécessaire 15 de modifier le fichier de description de la scène pour la mise en oeuvre du procédé de sécurisation selon cette variante de l'invention. Cela permet donc d'assurer la compatibilité avec les scènes déjà créées, auxquelles on souhaite appliquer le procédé de sécurisation selon l'invention. Cela permet également d'assurer la compatibilité avec des terminaux de 20 restitution de scène qui n'auraient pas les capacités de mise en oeuvre du procédé de sécurisation de l'invention. L'arbre de scène n'étant pas modifié, un tel terminal peut toujours restituer la scène, sans la mise en oeuvre de la sécurisation. 6.1 Description d'un premier exemple de réalisation On présente maintenant un premier exemple de mise en oeuvre de 25 l'invention dans le cadre de la sécurisation de l'interface graphique d'un terminal. Le moteur de rendu du terminal, ici de type "Rich Media" , est responsable de l'intégralité de l'interface du terminal. Le bureau, les icônes, les menus et tous les éléments d'interface sont des éléments décrits dans le format "Rich Media" , compris par le moteur de rendu.

Toutes les descriptions d'éléments d'interface contribuent à une même scène évolutive unique qui affiche le bureau ou la page de base du terminal. On suppose que le fabricant du terminal est l'entité qui a tous les droits d'origine, et que ce fabricant confère ensuite des droits limités, selon le procédé de sécurisation de l'invention, à certaines compagnies partenaires qui fournissent des applications pour le terminal. Parmi les éléments d'interface, certains sont créés par le fabricant du terminal, et d'autres sont fournis par les compagnies partenaires. Un droit minimal est conféré à chaque application, consistant à pouvoir : - intervenir sur l'interface pour créer une icône d'accès à l'application ; - se substituer au moteur de rendu pour contrôler le contenu de l'écran lorsque l'icône est activée ; - rendre le contrôle de l'écran au moteur de rendu lorsque l'utilisateur quitte l'application. De plus, le procédé de sécurisation selon l'invention permet de définir, pour une application, des droits de manière plus précise, comme par exemple : - le droit de rester active en permanence, et d'afficher au sein de l'interface graphique du terminal une icône d'état, ou des informations dynamiques comme un bandeau d'informations boursières ; - le droit d'écouter le clavier sur une touche particulière pour changer de mode actif/inactif ; - le droit d'ajouter un élément dans un menu pour changer de mode actif/inactif ; - le droit de prendre le contrôle de l'écran en cas d'inactivité (économiseur d'écran) ;

Ces droits correspondent à des règles de sécurisation pour l'interface 30 graphique du terminal. 25 Ensuite, des fournisseurs d'applications sont identifiés comme étant aptes à fournir des applications pour le terminal et susceptibles par conséquent de modifier l'interface graphique du terminal. Ces règles de sécurisation associées aux fournisseurs identifiés forment les différentes politiques de sécurité associées à l'interface graphique du terminal. Ensuite, lors de l'utilisation du terminal, et de la restitution de la scène correspondant à l'interface graphique du terminal, le procédé de mise à jour selon l'invention permet de détecter les applications non autorisées et les applications autorisées, assurant ainsi l'intégrité de l'interface graphique du terminal. 6.2 Description d'un deuxième exemple de réalisation On considère dans cet exemple la consommation de programmes de télévision sur des terminaux mobiles. Par défaut, on considère une scène de base avec une vidéo en plein écran et un objet audio. Divers éléments d'interface permettent de faire des opérations courantes, comme changer de chaîne ou augmenter le volume audio. Au sein de l'application TV, l'utilisateur peut également demander l'accès au guide des programmes, ce qui se concrétise par un ajout, dans la scène, d'objets graphiques et de texte décrivant le programme des heures suivantes, avec une interactivité permettant de se déplacer dans le guide et d'afficher d'autres parties du guide. La scène ainsi modifiée est alors beaucoup plus complexe que la scène de base, et change à chaque action utilisateur. On suppose que le fournisseur de l'application de TV mobile est aussi responsable du guide de programmes, donc tous les éléments ci-dessus sont fournis par la même source, qui possède la scène. La question de la sécurisation de la scène n'est alors pas primordiale, la seule source de modifications étant identifiée et autorisée en tant que fournisseur de l'application. Cependant, au cours de la restitution de la scène, il peut également se produire d'autres types d'événements que la consultation du guide des programmes, comme par exemple une interaction liée à une chaîne de programmes, par exemple un vote. Dans ce cas, un message doit apparaître en superposition avec le programme, puis des éléments d'interface pour voter (comme des boutons), puis le 5 cas échéant un message confirmant le vote effectué. Ensuite, tous les éléments ajoutés pour le vote doivent disparaître. Ces modifications sont issues d'une source autre que le fournisseur de l'application de TV mobile et doivent donc être sécurisées. Pour ce faire, et permettre cette interaction, le procédé de sécurisation 10 selon l'invention définit les autorisations suivantes : - autorisation pour la source des interactions liées à la chaîne de programmes d'ajouter des éléments dans un groupe d'éléments donné A (pour créer les éléments d'interface du vote, c'est-à-dire les boutons et les messages) ; 15 - autorisation pour la source des interactions liées à la chaîne de programmes de faire toute action sur les éléments présents dans A (pour supprimer les éléments d'interface du vote à la fin) ; - autorisation de capturer et de traiter un sous-ensemble des évènements clavier/écran tactile (pour tenir compte du vote de 20 l'utilisateur) ; - interdiction de toute autre opération qui modifierait le fonctionnement de l'application de TV mobile au-delà des limites du vote. Une fois ces règles de sécurisation définies, le procédé de sécurisation les 25 associe à des identifiants de sources autorisées, correspondant aux sources fournissant les données aux chaînes de programmes, afin de définir des politiques de sécurité pour la scène. Ensuite, au moment où l'utilisateur interagit avec la scène en cours de restitution, le procédé de mise à jour selon l'invention applique ces politiques de sécurités pour autoriser ou non des actions sur la scène, en fonction des sources (les chaînes de TV) et des autorisations prédéfinies. Un autre type d'événements peut se produire dans le cadre d'une application de TV mobile : les événements prioritaires, comme par exemple une alerte enlèvement , c'est-à-dire une alerte venant des autorités, et qui doit remplacer ce qui est affiché, puis laisser l'émission reprendre sans modifications. Les droits à définir sont sensiblement équivalents à ceux définis précédemment dans le cas du vote, à ceci près que l'élément groupant A doit obligatoirement être visible et disposé de manière que ses sous-éléments soient affichés devant tout le reste de la scène. 6.3 Description d'un troisième exemple de réalisation On considère une scène évolutive comprenant deux groupes : - le groupe 1 est un groupe destiné à recevoir des éléments envoyés par le serveur principal de la scène (serveur P), et n'a pas de politique de sécurité associée (cela signifie que seul le serveur d'origine P de l'élément cible de la mise à jour a le droit de modifier l'élément) ; - le groupe 2 est destiné à recevoir des éléments venant d'une source extérieure particulière (serveur E) et une politique de sécurité lui est attribuée, définie par le procédé de sécurisation selon l'invention, autorisant toutes les actions venant du serveur E ; - le groupe 3 est destiné à recevoir des éléments venant d'une source extérieure particulière (serveur X) et une politique de sécurité lui est attribuée, définie par le procédé de sécurisation selon l'invention, autorisant toutes les actions venant du serveur X. Lors de la restitution de la scène, celle-ci reçoit une première commande d'insertion d'éléments dans le groupe 1. Le procédé de mise à jour selon l'invention détermine dans un premier temps que l'origine de la commande est le serveur S. Il vérifie que ce serveur S fait partie d'au moins une des politiques de sécurité associée à la scène.

Le procédé détermine ensuite, en décodant la commande, que la cible de l'insertion est le groupe 1 (n'ayant pas de politique de sécurité). Le procédé de mise à jour décide donc que la commande est légale selon les contraintes de sécurité, et l'exécute.

La scène reçoit ensuite une seconde commande d'insertion dans le groupe 1 depuis un serveur X autre que le serveur S. Après avoir déterminé que l'origine de la commande est un serveur X, et que ce serveur fait bien partie d'une des politiques de sécurité de la scène, le procédé de mise à jour selon l'invention détermine que ce serveur n'est pas autorisé à agir de quelque manière que ce soit sur le groupe 1, cible de la commande. Cette commande n'est pas légale et est donc ignorée. La scène reçoit une troisième commande d'insertion dans le groupe 2, provenant du serveur E.

Le procédé de mise à jour selon l'invention détermine que l'origine de la commande est le serveur E, par exemple en utilisant un mécanisme de signature de la commande qui permet de vérifier son origine et l'absence de modifications lors du transport. Le procédé vérifie que ce serveur E fait bien partie d'au moins une des politiques de sécurité de la scène, puis décode la commande pour déterminer que la cible de l'insertion est le groupe 2 (qui a une politique de sécurité qui autorise les commandes venant du serveur E). La commande est donc légale et est exécutée. La scène reçoit une quatrième commande d'insertion dans le groupe 2, 25 provenant d'un serveur Y. Le procédé de mise à jour selon l'invention détermine que l'origine de la commande est le serveur Y. Le procédé constate que ce serveur Y ne fait partie d'aucune politique de sécurité de la scène et ignore donc la commande, sans même la décoder. 30

Claims (19)

1. REVENDICATIONS1. Procédé de sécurisation d'une scène évolutive composée d'au moins un élément et destinée à être restituée sur un terminal, caractérisé en ce que ledit procédé comprend les étapes suivantes : - création (10) d'au moins une règle de sécurisation, définissant au moins une autorisation de modification de ladite scène et/ou d'au moins un élément de ladite scène et/ou une autorisation d'exécution d'au moins une commande dans un contexte de restitution de ladite scène sur ledit terminal ; - attribution (11) d'une politique de sécurité, comprenant au moins une desdites règles de sécurisation, à ladite scène et/ou à au moins un desdits éléments de ladite scène.
2. 2. Procédé de sécurisation selon la revendication 1, caractérisé en ce que ladite politique de sécurité est définie dans un fichier ou un flux distinct d'un 15 fichier ou un flux de description de ladite scène évolutive.
3. 3. Procédé de sécurisation selon la revendication 1, caractérisé en ce que ladite politique de sécurité est définie dans un fichier ou un flux de description de ladite scène évolutive.
4. 4. Procédé de sécurisation selon l'une quelconque des revendications 1 à 3, 20 caractérisé en ce que ledit procédé comprend les étapes suivantes : - obtention d'au moins une information d'identification d'au moins une source apte à modifier ladite scène et/ou à modifier un contexte de restitution de ladite scène ; - association, dans ladite politique de sécurité, de ladite au moins une 25 information d'identification à au moins une règle de sécurisation de ladite politique de sécurité.
5. 5. Procédé de sécurisation selon l'une quelconque des revendications 1 à 4, caractérisé en ce que lesdits éléments sont organisés selon une arborescence associant à au moins un élément père au moins un élément fils, et en ce qu'une 30 politique de sécurité attribuée audit élément père s'applique par défaut égalementaudit au moins un élément fils.
6. 6. Procédé de sécurisation selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il comprend une étape de définition d'au moins un groupe constitué d'éléments de ladite scène partageant une même politique de sécurité.
7. 7. Procédé de sécurisation selon l'une quelconque des revendications 1 à 6, caractérisé en ce que lesdites modifications appartiennent au groupe comprenant au moins : - une insertion d'un élément dans ladite scène ; - une modification d'un élément dans ladite scène ; - une suppression d'un élément dans ladite scène ; - une modification d'un attribut dans ladite scène ; - une suppression d'un attribut dans ladite scène ; - une modification d'une politique de sécurité dans ladite scène.
8. 8. Procédé de sécurisation selon l'une quelconque des revendications 1 à 7, caractérisé en ce que lesdites règles de sécurisation comprennent au moins une information appartenant au groupe comprenant au moins : - une restriction d'application d'une modification à un élément de ladite scène ; - une restriction d'application d'une modification à un groupe d'éléments de ladite scène ; - une restriction d'application d'une modification à tous les éléments d'un type prédéfini de ladite scène ; - une restriction d'application d'une modification à un type d'attributs de ladite scène ; - une restriction d'application d'une modification en fonction d'au moins un critère prédéterminé ; - une restriction d'exécution d'une commande ou d'un groupe de commandes dans un contexte donné de ladite scène.
9. 9. Procédé de sécurisation selon l'une quelconque des revendications 4 à 8, caractérisé en ce que lesdites informations d'identification appartiennent augroupe comprenant au moins : - un identifiant ; - une adresse IP ; - un certificat utilisé pour signer un contenu transmis par ladite source.
10. 10. Procédé de mise à jour d'une scène évolutive créée selon la revendication 1, ladite scène étant composée d'au moins un élément et destinée à être restituée sur un terminal, caractérisé en ce que ledit procédé comprend les étapes suivantes : - réception (20), en provenance d'une source et/ou d'un canal de transmission de données, d'une demande de mise à jour pour un élément de ladite scène évolutive, un groupe d'éléments de ladite scène évolutive, ou ladite scène évolutive entière et/ou d'une demande d'exécution d'une commande dans un contexte de restitution de ladite scène évolutive ; - acceptation ou refus (21) de ladite demande de mise en jour et/ou demande d'exécution d'une commande, en fonction d'une politique de sécurité attribuée audit élément, ou audit groupe ou à ladite scène.
11. 11. Procédé de mise à jour d'une scène évolutive selon la revendication 10, caractérisé en ce qu'il comprend une étape d'identification de ladite source, délivrant une information d'identification, et en ce que ladite étape d'acceptation tient compte d'une politique de sécurité associée à ladite information d'identification.
12. 12. Procédé de mise à jour d'une scène évolutive selon la revendication 11, caractérisé en ce que ladite information d'identification est fournie par un moyen d'accès à ladite mise à jour et/ou ladite commande.
13. 13. Procédé de mise à jour d'une scène évolutive selon la revendication 11, caractérisé en ce que ladite information d'identification est présente dans ladite mise à jour et/ou ladite commande et/ou est transmise avec ladite mise à jour et/ou ladite commande.
14. 14. Procédé de mise à jour d'une scène évolutive selon l'une quelconque des 30 revendications 10 à 13, caractérisé en ce que ladite étape d'acceptation ou refuscomprend les sous-étapes suivantes : - décodage de ladite mise à jour et/ou de ladite commande ; - identification d'une politique de sécurité associée audit élément ou audit groupe d'éléments ou à ladite scène concerné par ladite mise à jour ; - vérification de la présence d'une association de ladite information d'identification et d'au moins une règle de sécurisation correspondant à ladite mise à jour et/ou ladite commande décodée, dans ladite politique de sécurité identifiée, délivrant une décision d'acceptation de ladite mise à jour et/ou ladite commande si ladite vérification est positive.
15. 15. Signal représentatif d'une scène évolutive composée d'au moins un élément et destinée à être restituée sur un terminal, caractérisé en ce que ledit signal comprend au moins un champ de sécurisation comprenant au moins une information représentative d'une politique de sécurité, comprenant au moins une règle de sécurisation définissant au moins une autorisation de modification dudit élément et/ou de ladite scène, de façon à permettre ou interdire, dans un terminal, une modification requise par une source, en fonction de ladite politique.
16. 16. Dispositif de sécurisation d'une scène évolutive composée d'au moins un élément et destinée à être restituée sur un terminal, caractérisé en ce que ledit dispositif comprend : - des moyens de création d'au moins une règle de sécurisation, définissant au moins une autorisation de modification de ladite scène et/ou d'au moins un élément de ladite scène et/ou une autorisation d'exécution d'au moins une commande dans un contexte de restitution de ladite scène sur ledit terminal ; - des moyens d'attribution d'une politique de sécurité, comprenant au moins une desdites règles de sécurisation, à ladite scène et/ou à au moins un desdits éléments de ladite scène.
17. 17. Dispositif de mise à jour d'une scène évolutive, ladite scène étant 30 composée d'au moins un élément et destinée à être restituée sur un terminal,caractérisé en ce que ledit dispositif comprend : - des moyens de réception, en provenance d'une source et/ou d'un canal de transmission de données, d'une demande de mise à jour pour un élément de ladite scène évolutive, un groupe d'éléments de ladite scène évolutive, ou ladite scène évolutive entière et/ou d'une demande d'exécution d'une commande dans un contexte de restitution de ladite scène évolutive ; - des moyens d'acceptation ou refus de ladite demande de mise en jour et/ou demande d'exécution d'une commande, en fonction d'une politique de sécurité attribuée audit élément, ou audit groupe ou à ladite scène.
18. 18. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé de sécurisation selon l'une au moins des revendications 1 à 9, lorsque ledit programme est exécuté sur un ordinateur.
19. 19. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé de mise à jour selon l'une au moins des revendications 10 à 14, lorsque ledit programme est exécuté sur un ordinateur.