PROCèDE ET DISPOSITIF D'ADAPTATION AU CONTEXTE PHYSIQUE D'UNE APPLICATION METTANT EN œUVRE DES MECANISMES DE SECURITE RECONFIGURABLES

La présente invention concerne un procédé et un dispositif d'adaptation du niveau de sécurité d'une application en fonction de l'environnement physique dans lequel s'exécute au moins une partie de l'application.

Plus particulièrement, l'invention concerne les environnements d'intelligence ambiante qui nécessitent que la sécurité des applications soit apte à s'adapter à des conditions d'environnement particulières. La complexité et l'hétérogénéité de ces environnements introduisent de nombreuses vulnérabilités donnant naissance à des exigences de sécurité nouvelles.

Par ailleurs, l'intégration de la sécurité dans des applications nouvelles et sensibles est importante en termes de confiance pour les utilisateurs.

On appelle contexte physique, l'environnement physique dans lequel s'exécute au moins une partie de l'application ; ce contexte est, notamment, celui de l'utilisateur principal de l'application. Selon une méthode décrite dans le document intitulé « Cerberus: A

Context-Aware Security Scheme for Smart Spaces » de J. Al-Muhtadi, A. Ranganathan, R. Campbell, et M. Mickunas, présenté à la conférence « International Conférence on Pervasive Computing (PerCom) » de 2003, la sécurité des applications est mise à jour par modification de paramètres de l'application en fonction du contexte d'exécution de l'application.

Selon cette méthode, des politiques de sécurité, notamment en termes d'authentification et de contrôle d'accès, définissant différents niveaux

de sécurité, tiennent compte d'informations contextuelles, particulièrement pour le contexte physique. Ces informations contextuelles sont obtenues au moyen d'une infrastructure de gestion de contexte.

Toutefois, cette méthode présente l'inconvénient que seuls certains paramètres décrivant la configuration du système de sécurité peuvent être modifiés, ce qui limite les adaptations possibles.

II est également connu, notamment du document intitulé « Secure Vérification of Location Claims » de N. Sastry, U. Shankar, et D. Wagner, publié dans le colloque « ACM Workshop on Wireless Security » (pages 1 à 10) en 2003, une méthode d'utilisation et de vérification de données de localisation pour permettre un contrôle d'entrée dans un bâtiment sur la base de ces données.

Toutefois, cette méthode ne permet de gérer qu'un seul type de données de contexte, celui ayant trait à la localisation. De plus, elle se limite à une seule manière de décrire la confiance que l'on peut avoir dans ces données, en se restreignant à l'authentification des données de contexte pour qualifier cette confiance.

Il est également connu, notamment du document intitulé « Security Ontology for Annotating Resources » de A. Kim, J. Luo, et M. Kang, présenté à la conférence « International Conférence on Ontologies, Databases, and Applications of Semantics (ODBASE) » en 2005, une méthode pour formaliser sous la forme d'ontologies les différentes manières de qualifier la confiance d'informations de contexte, en se limitant au domaine de la sécurité.

Toutefois, cette méthode ne divulgue nullement l'adaptation des mécanismes de sécurité du système en fonction de ces données de contexte.

L'invention vise à remédier à au moins un des inconvénients de l'art antérieur en proposant un procédé d'adaptation dynamique d'une application mettant en œuvre des mécanismes de sécurité, caractérisé en ce qu'il comprend les étapes suivantes : - détermination d'au moins une information de contexte de l'environnement physique dans lequel s'exécute au moins une partie de l'application ;

- détermination d'un niveau de sécurité selon ladite au moins une information de contexte déterminée ;

- décision de reconfiguration/non-reconfiguration fondée au moins sur une comparaison entre le niveau de sécurité déterminé et le niveau de sécurité courant appliqué par les mécanismes de sécurité ; et

- en cas de décision positive, reconfiguration de l'application pour adapter l'application au niveau de sécurité déterminé.

La présente invention permet d'adapter de manière automatique les politiques et mécanismes de sécurité utilisés dans un environnement d'intelligence ambiante en fonction d'informations de contexte sur l'environnement physique dans lequel s'exécute l'application, notamment de l'environnement de l'utilisateur.

Ainsi, l'invention établit un lien renforcé entre le niveau de sécurité de l'application et l'environnement physique détecté, par exemple par des capteurs en réseau dans les environnements d'intelligence ambiante, de manière à rendre possible l'adaptation des mécanismes de sécurité au contexte physique.

Pour ce faire, l'application subit une reconfiguration dynamique, notamment des mécanismes de sécurité, en fonction de l'état de l'environnement déterminé, par exemple par des capteurs. Selon l'invention, il est permis une reconfiguration de la politique de sécurité à un niveau macroscopique, et une reconfiguration des mécanismes de sécurité à un niveau plus fin.

L'adaptation dynamique de la sécurité d'une application à un contexte physique peut aller jusqu'à une reconfiguration complète du mécanisme de sécurité, notamment, par ajout ou retrait de fonctionnalités dans l'application, par exemple, par l'introduction de nouveaux composants de sécurité.

Ainsi, selon l'invention, les opérateurs et les fournisseurs de services ont l'assurance de l'existence d'une sécurité minimale garantie par le système au travers des reconfigurations, alors que les utilisateurs pourraient désactiver totalement une sécurité manuelle traditionnelle qui leur semblerait trop lourde à utiliser.

En outre, par exemple, dans Ie cas des systèmes de type 4G (4 ^ιeme génération), selon l'invention, il est permis de surmonter l'hétérogénéité des réseaux mobiles existants, notamment, afin qu'un utilisateur équipé d'un terminal reconfigurable et attentif au contexte ait l'impression d'être connecté à un réseau unique, par exemple à un réseau IP (« Internet Protocol » en terminologie anglo-saxonne). L'utilisateur se déplaçant à travers de nombreux types d'environnements, chacun étant caractérisé par sa propre politique de sécurité, cette adaptation est aussi nécessaire sur l'infrastructure de sécurité.

Selon un mode de réalisation particulier, l'étape de détermination d'au moins une information de contexte de l'environnement physique comprend au moins une étape d'acquisition de données contextuelles.

Tel que décrit précédemment, l'acquisition des données contextuelles est réalisée directement à partir de l'environnement physique, par exemple au moyen de capteurs présents dans l'environnement physique. Selon un mode de réalisation, le procédé comprend une étape d'authentification de ladite au moins une information de contexte.

Selon cette caractéristique, l'adaptation de la sécurité de l'application dépend du niveau d'authentification des informations de contexte.

L'authentification d'informations de contexte permet aussi d'alléger les mécanismes de sécurité, en prenant en compte par exemple des dispositifs de protection physique déjà présents dans l'environnement.

Selon une autre caractéristique, le procédé comprend une étape d'association d'au moins un degré de confiance à ladite au moins une information de contexte déterminée. Selon un mode de réalisation, l'étape de décision est en outre fonction dudit au moins un degré de confiance associé à ladite au moins une information de contexte déterminée.

Selon cette caractéristique, le niveau de sécurité de l'application est mis à jour par reconfiguration en fonction de la fiabilité de l'information de contexte. Ainsi, l'adaptation de la sécurité d'une application vers un niveau de faible sécurité ne pourra avoir lieu que sur la base d'une information de contexte dont la fiabilité est suffisante.

Selon une caractéristique particulière, ledit au moins un degré de confiance est défini selon une ontologie.

Selon une autre caractéristique, l'ontologie définit au moins une règle de traitement de ladite au moins une information de contexte associée. Selon un mode de réalisation, le procédé comprend une étape de construction d'une réputation pour au moins une information de contexte déterminée en fonction dudit au moins un degré de confiance associé à ladite au moins une information de contexte déterminée.

Par construction d'une réputation, on entend la détermination de valeurs de sécurité et / ou de sûreté et / ou données personnelles, etc.

Selon une caractéristique, ladite réputation comprend une pluralité de dimensions, chaque dimension étant un degré de confiance qualifiant ia confiance dans l'information de contexte ou de son traitement.

Selon encore une caractéristique particulière, ladite réputation comprend au moins une relation entre les dimensions de qualification de la confiance.

Dans un mode de réalisation particulier, une ontologie définit ladite au moins une relation entre les dimensions de qualification de la confiance.

Selon une caractéristique particulière, le procédé comprend une étape d'association d'au moins une information de contextualité à ladite au moins une information de contexte déterminée qualifiant ladite au moins une information de contexte en fonction de son niveau d'importance.

Corrélativement, l'invention fournit également un dispositif d'adaptation dynamique d'une application mettant en œuvre des mécanismes de sécurité, caractérisé en ce qu'il comprend les moyens suivants :

- des moyens de détermination d'au moins une information de contexte de l'environnement physique dans lequel s'exécute au moins une partie de l'application ;

- des moyens de détermination d'un niveau de sécurité selon ladite au moins une information de contexte déterminée ;

- des moyens de décision de reconfiguration/non-reconfiguration fondés au moins sur des moyens de comparaison entre le niveau de sécurité

déterminé et le niveau de sécurité courant appliqué par les mécanismes de sécurité ; et

- des moyens de reconfiguration de l'application pour adapter l'application au niveau de sécurité déterminé. Ce dispositif présente essentiellement les mêmes avantages que le procédé d'adaptation d'une application mettant en œuvre des mécanismes de sécurité brièvement décrit ci-dessus.

Selon encore un autre aspect, l'invention concerne un programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en œuvre du procédé d'adaptation d'une application mettant en œuvre des mécanismes de sécurité tel qu'exposé ci-dessus, lorsque ce programme est chargé et exécuté par le système informatique.

Selon encore un aspect, l'invention fournit également un produit programme d'ordinateur pouvant être chargé dans un appareil programmable, caractérisé en ce qu'il comporte une application mettant en œuvre des mécanismes de sécurité, des moyens de détermination d'au moins une information de contexte de l'environnement physique dans lequel s'exécute au moins une partie de l'application, des moyens de détermination d'un niveau de sécurité selon ladite au moins une information de contexte déterminée, des moyens de décision de reconfiguration/non-reconfiguration fondés au moins sur des moyens de comparaison entre le niveau de sécurité déterminé et le niveau de sécurité courant appliqué par les mécanismes de sécurité et des moyens de reconfiguration de l'application pour adapter l'application au niveau de sécurité déterminé.

D'autres aspects et avantages de la présente invention apparaîtront plus clairement à la lecture de la description qui va suivre, cette description étant donnée uniquement à titre d'exemple non limitatif et faite en référence aux dessins annexés, dans lesquels : - la Figure 1 illustre un modèle d'architecture à composants ;

- Ia Figure 2 illustre une architecture logicielle ou matérielle d'adaptation des fonctionnalités de sécurité d'une application en fonction de l'environnement physique conformément à l'invention ;

- la Figure 3 représente un algorithme d'adaptation du niveau de sécurité d'une application conformément à l'invention ;

- la Figure 4 illustre une opération d'authentification sur la base d'informations de localisation ;

- la Figure 5 illustre les nœuds du système de gestion de contexte ;

- la Figure 6 illustre une ontologie structurelle pour un système de gestion de contexte;

- la Figure 7 illustre une ontologie de qualification de la confiance ;

- la Figure 8 illustre les relations entre l'ontologie de qualification de la confiance et l'ontologie structurelle ;

- la Figure 9 illustre une architecture d'un nœud de gestion de contexte ;

- la Figure 10 illustre une infrastructure de gestion de la réputation ;

- la Figure 11 illustre une architecture globale de gestion de contexte ;

- la Figure 12 illustre une implantation du système de gestion de contexte ;

- la Figure 13 illustre un contrôle d'accès basé sur la localisation avec une adaptation du système à un changement des caractéristiques de cette localisation ;

- la Figure 14 illustre un contrôle d'accès basé sur la localisation avec prévention d'usurpation de l'information de localisation ; et

- la Figure 15 illustre une interface de type « follow-me ».

Selon l'invention, la sécurité d'une application s'exécutant dans un environnement d'intelligence ambiante est adaptée de manière automatique par reconfiguration dynamique de l'application selon des politiques et des mécanismes de sécurité utilisés dans cet environnement. Cette adaptation est

réalisée en fonction d'informations sur l'état de l'environnement dans lequel s'exécute au moins une partie de l'application.

L'environnement conditionne, conformément à l'invention, le contexte physique dans lequel s'exécute au moins une partie de l'application. Il s'agit, notamment du contexte physique de l'utilisateur de l'application. Le contexte physique est déterminé à partir d'informations acquises par l'intermédiaire de capteurs répartis dans l'environnement.

Les capteurs sont aptes, par exemple, à déterminer la position de l'utilisateur, et plus généralement les éléments pertinents du contexte dans lequel est l'utilisateur (seul dans un bureau, en réunion, engagé dans une activité non-interruptible, et ainsi de suite).

Selon un mode de réalisation, le contexte physique peut être géré au moyen d'un système de gestion de contexte.

En outre, conformément à l'invention, l'adaptation de l'application peut également être réalisée en fonction du niveau de confiance des informations contextuelles obtenues.

Par exemple, l'adaptation de la sécurité d'une application vers un niveau de sécurité plus faible ne peut être faite qu'en fonction d'informations contextuelles au sujet desquelles on peut avoir un degré de confiance suffisant, et dont l'authenticité est assurée.

L'adaptation du niveau de sécurité d'une application a pour objectif d'assurer une protection « juste suffisante », sans surcharger l'utilisateur par des mécanismes de sécurité surdimensionnés, redondants ou inadaptés.

Par exemple, selon un premier mode de réalisation, la sécurité de l'application est adaptée, voire associée à la sécurité des dispositifs de protection physique existant par ailleurs dans l'environnement de l'utilisateur.

Ainsi, par exemple, en exploitant l'information de localisation de l'utilisateur comme élément de contexte, le processus d'authentification de l'application peut être allégé si l'utilisateur est présent dans un local dont l'accès est déjà protégé par un mécanisme de sécurité physique traditionnel, par exemple, une porte fermant à clef ou un dispositif de sécurité biométrique.

Plus généralement, les informations contextuelles déterminées, notamment au moyen des capteurs, par exemple la nature de l'activité en cours, sont utilisées pour déclencher une adaptation des mécanismes de sécurité de l'application, si nécessaire. II est ainsi rendu possible de sélectionner automatiquement le niveau de sécurité de l'application adapté à son bon fonctionnement, sans surcharger inutilement l'attention de l'utilisateur en lui demandant, par exemple, son approbation pour chaque opération d'adaptation du niveau de sécurité de l'application. Selon un mode de réalisation des applications, celles-ci sont conçues selon une approche à base de composants logiciels tels qu'illustré en Figure 1. Les composants logiciels sont définis comme des entités encapsulant du code et des données qui apparaissent dans les systèmes logiciels comme des unités d'exécution, de configuration / reconfiguration, de déploiement ou d'administration.

La construction d'une application selon un modèle composant permet de maîtriser la complexité de mise en œuvre de l'infrastructure logicielle, puisque les composants peuvent être eux-mêmes composés pour former des unités de code de haut niveau. Une application conçue selon un modèle composant permet également une flexibilité dans la configuration choisie puisque les fonctionnalités de l'application peuvent être adaptées ou introduites par ajout ou remplacement de composants dans l'application.

Ainsi, selon le modèle composant, une application est reconfigurable et donc rend flexible le choix de composants.

Un composant est une entité exécutable construite à partir d'un contrôleur qui supervise son exécution. Un composant composite est comparable à une boîte blanche dans lequel des composants, appelés composants primitifs, sont interconnectés. Ces composants primitifs sont considérés comme des boîtes noires. En effet, ils encapsulent le code logiciel.

Un composant peut seulement interagir avec son environnement au travers d'un ensemble de points d'accès bien déterminés appelés interfaces.

Les interactions entre les composants nécessitent l'établissement de liaisons entre les interfaces de ces composants.

La Figure 2 illustre une architecture logicielle et / ou matérielle d'adaptation d'une application en fonction de son environnement physique d'exécution conformément à l'invention.

Cette architecture comprend notamment un service de sécurité 21 flexible apte à permettre l'adaptation du mécanisme de sécurité ou du niveau de sécurité d'une application, ensuite une infrastructure d'acquisition, d'agrégation et de gestion de contexte 22 appelée ci-dessous "système de gestion de contexte", un moteur d'inférence 23 du contexte de sécurité à partir du contexte physique déterminé et un mécanisme de décision d'adaptation du service de sécurité 24 en fonction d'informations sur le contexte de sécurité.

En outre, cette architecture peut également comprendre un service d'authentification d'informations de contexte 25. Conformément à l'invention, l'adaptation de la sécurité d'une application en fonction du contexte physique de l'utilisateur s'effectue selon le procédé suivant.

Tout d'abord, le système de gestion de contexte 22, réparti ou centralisé, obtient des données de contexte de bas niveau. Ces données concernent notamment des grandeurs physiques, par exemple, fournies par un réseau de capteurs Ci disposés dans l'environnement dans lequel s'exécute l'application.

Ces grandeurs peuvent être, par exemple, une température, une pression, une distance par rapport à un point de référence, une localisation. Ces grandeurs sont ensuite agrégées en vue de déterminer des informations de contexte de plus ou moins haut niveau, comme par exemple, la position ou la posture de l'utilisateur par rapport à un référentiel pertinent, l'état de l'environnement, l'activité au sein de cet environnement, la situation, le niveau de bruit ambiant. On peut ainsi inférer à partir des données de contexte de bas niveau, des informations sur les activités en cours dans l'environnement qui permettront d'adapter la sécurité de l'application s'exécutant dans cet environnement.

Un mode de réalisation du système de gestion de contexte 22 est décrit ci-après en référence aux Figures 5 à 12.

Ensuite, le service d'authentification d'informations de contexte 25 peut associer aux informations de contexte précédemment déterminées un degré de contextualité qui serait par exemple strictement compris entre 0 et 1 , 0 correspondant à des informations inutiles et 1 à des informations importantes pour le système. Ce(s) degré(s) de contextualité peuvent ultérieurement être pris en compte lors de l'adaptation du niveau de sécurité de l'application par le service de sécurité 21. Ainsi, qualifier ces informations de contexte permet de moduler leur utilisation pour l'adaptation de la sécurité d'une application.

Selon un mode particulier de réalisation, on associe, lors du traitement des informations de contexte, aux informations de contexte un degré de confiance de type sécurité fournis par le service d'authentification d'informations de contexte 25 et un degré de confiance de type fiabilité.

De la sorte, si les informations de contexte sont « à faible confiance », elles ne seront typiquement pas utilisées pour des adaptations critiques alors qu'elles pourraient l'être pour des adaptations sans conséquence pour la sécurité. Cette notion de confiance ou de qualité des données de contexte peut revêtir de nombreux aspects. En effet, il peut s'agir de confiance en termes de fiabilité, de précision, de sécurité classique, de confidentialité {données non espionnées), d'intégrité (données non altérées de manière malveillante) ou d'authenticité (une source de données n'est pas substituée par une autre). Cette confiance peut aussi être reliée au respect de la vie privée (autorisation plus ou moins restreinte d'accès aux données par des tiers).

Ainsi, le service d'authentification d'informations de contexte 25 est apte à attacher aux informations de contexte, voire aux données brutes acquises, des métadonnées intégrant ces différentes dimensions de confiance. Ces métadonnées peuvent également être modifiées en tenant compte des traitements appliqués sur les données tout au long de leur traitement et de leur agrégation.

Ensuite, à partir des informations de contexte et des degrés de confiance ou métadonnées, le moteur d'inférence 23 déduit le contexte de sécurité adéquat Cs. Ce dernier est, par exemple, le niveau de sécurité pour l'application adapté à l'activité ou à la situation courante d'exécution de l'application en termes d'environnement.

Toutefois, la notion de contexte de sécurité peut être plus générale qu'un simple niveau de sécurité.

En effet, les informations du contexte à partir desquelles le moteur d'inférence déduit le contexte de sécurité courant peuvent être décrites dans une ontologie formelle de sécurité, et il en est de même pour les informations issues du moteur d'inférence.

Le contexte de sécurité adéquat Cs est ensuite transmis de manière sécurisée au mécanisme de décision d'adaptation du service de sécurité 24.

Ce contexte de sécurité adéquat Cs peut aussi être utilisé pour adapter le service d'authentification d'informations de contexte 25. En effet, selon ce contexte de sécurité, le niveau d'authentification est plus ou moins élevé en fonction du niveau de sécurité requis.

Enfin, à partir des informations authentifiées de contexte de sécurité, le mécanisme de décision 24 déclenche ou non la reconfiguration ou le paramétrage de l'adaptation du service de sécurité 21.

Considérons un exemple dans lequel on effectue une adaptation de la sécurité d'une application en fonction du contexte des algorithmes cryptographiques assurant la protection des échanges réseau.

Selon cet exemple, le niveau de sécurité est fort lors des communications émises et reçues par le terminal de l'utilisateur présent dans un environnement hostile et peu sécurisé.

Un environnement hostile où le risque d'interception des communications n'est pas négligeable est, par exemple, un pays à risque ou une entreprise concurrente. Le niveau de sécurité élevé est atteint, notamment, par l'utilisation d'un algorithme robuste de chiffrement, par exemple, au moyen d'un algorithme

cryptographique de type AES ou standard de chiffrement avancé (« Advanced Encryption Standard » en terminologie anglo-saxonne).

En outre, les longueurs de clé doivent notamment rester supérieures aux capacités actuelles de cryptanalyse pour éviter des attaques par dictionnaire ou par force brute.

Au contraire, lorsque l'environnement de l'utilisateur est déjà protégé par des mécanismes de sécurité physique et/ou informatique, tel que, par exemple, une salle de réunion fermée à clé, un environnement domestique ou d'entreprise protégé par un pare-feu {« firewall » en terminologie anglo- saxonne), le niveau de sécurité de l'application peut être atténué, notamment au niveau de la protection des communications.

De cette manière, la redondance des mécanismes de sécurité, notamment le cumul d'algorithmes de chiffrement à différents niveaux d'une pile protocolaire (par exemple du chiffrement au niveau de la couche Wifi combiné avec des mécanismes IPSec, SSL et du chiffrement applicatif) est évité.

En outre, par exemple, un meilleur temps de réponse sur des connections réseau lentes est disponible, les capacités de calcul et de communication des objets impliqués, par exemple des objets de type « smart dust » en terminologie anglo-saxonne ou « poussière intelligente », pouvant être limitées.

Pour ce faire, un algorithme moins robuste de chiffrement, par exemple un algorithme cryptographique de type DES ou Standard de Chiffrement de Données (« Data Encryption Standard » en terminologie anglo- saxonne) et/ou des longueurs de clé plus faibles sont utilisés. Cet assouplissement des mesures de sécurité peut également être nécessaire lorsque l'utilisateur nomade se trouve dans un pays où l'utilisation de la cryptographie est réglementée, les longueurs de clé devant rester inférieures à une taille limite.

Le service de sécurité considéré dans cet exemple est une bibliothèque cryptographique utilisée pour chiffrer et/ou signer les communications.

Selon le degré de flexibilité de ces mécanismes cryptographiques, l'application conçue selon un modèle composant peut subir une opération de reconfiguration afin de faire évoluer l'application vers un niveau de sécurité plus fort. Pour ce faire, la reconfiguration est réalisée par le téléchargement d'une nouvelle bibliothèque cryptographique fournissant des algorithmes plus robustes ou comportant des longueurs de clé plus importantes.

La reconfiguration d'une application est réalisée, par exemple, selon les étapes décrites ci-après en référence à la Figure 3.

L'algorithme débute à l'étape 31 consistant en l'acquisition de données de contexte à partir de l'environnement de l'utilisateur, notamment au moyen du système de gestion de contexte 22.

Selon un mode de réalisation particulier, cette étape est réalisée au moyen d'une système de détermination de localisation qui permet de localiser l'utilisateur par rapport à un référentiel, à savoir le pays dans lequel se trouve l'utilisateur, la position de l'utilisateur par rapport à un environnement déjà sécurisé, par exemple, un environnement intérieur ou extérieur du domicile, d'une salle de réunion, ou d'une entreprise.

Selon un autre mode de réalisation, cette étape est réalisée par agrégation d'informations de bas niveau provenant de plusieurs systèmes de détermination de localisation. Les données de localisation ainsi agrégées et consolidées sont alors transmises au service d'authentification 25 pour s'assurer de leur authenticité.

L'étape 31 est suivie de l'étape 32 consistant à authentifier le contexte utilisateur, notamment au moyen du service d'authentification 25. Au cours de cette étape, on s'assure que les données de contexte produites lors de l'étape 31 sont authentiques, qu'elles ont été générées par une infrastructure de localisation 22 digne de confiance, et qu'elles n'ont pas été modifiées par un tiers malveillant.

Ainsi, il s'agit d'éviter des attaques sur des systèmes où les droits d'accès dépendent directement de la localisation et où un tiers peut obtenir un accès illégitime à des services en falsifiant sa localisation.

Selon un mode de réalisation particulier, si lors de l'étape 31 , un certificat d'attributs est généré et signé par l'infrastructure de localisation où l'attribut du certificat contient les informations de localisation, lors de l'étape 32, cette dernière consiste alors en la vérification du certificat, en s'assurant que la signature de l'infrastructure de localisation est valide.

L'étape 32 est suivie de l'étape 33 au cours de laquelle on infère le contexte de sécurité, notamment au moyen du moteur d'inférence 23.

Le moteur d'inférence déduit le niveau de sécurité de l'environnement en comparant les données de localisation fournies lors des étapes 31 et 32 au niveau de sécurité de l'application.

Cette politique comprend, par exemple, les règles d'utilisation de la cryptographie dans le pays où se trouve l'utilisateur. Ces règles peuvent être de la forme :

Si pays = USA alors longueur_clé = court. Selon cette règle, il est tenu compte des restrictions potentielles sur l'utilisation de la cryptographie aux USA.

Si pays = FRANCE alors longueur_clé = long.

Ou :

Si extérieur_du__domicile(position) alors longueurjclé = long. Sinon, longυeur_clé = court.

Selon ces règles, en fonction de la localisation de l'utilisateur, à savoir à l'intérieur ou à l'extérieur du domicile, on affecte la variable « longueur_clé » représentant le niveau de sécurité en termes de longueur de la clé cryptographique à la valeur court ou long. L'étape 33 est suivie de l'étape 34 consistant à transmettre de manière sécurisée le contexte de sécurité déterminé, c'est-à-dire le niveau de sécurité courant adéquat, notamment au mécanisme de décision 24.

Pour ce faire, l'attribut longueur_clé mis à jour lors de l'étape 33 est alors transmis de manière sécurisée au mécanisme de décision 24, par exemple, après avoir été chiffré à l'aide d'une clé symétrique partagée entre le moteur d'inférence et le mécanisme de décision.

L'étape 34 est suivie de l'étape 35 au cours de laquelle on prend la décision de reconfigurer ou non l'application, notamment au moyen du mécanisme de décision 24.

Lors de cette étape, en fonction du contexte de sécurité reçu lors de l'étape 34, le mécanisme de décision 24 prend ou non la décision de déclencher l'opération de reconfiguration du composant mécanisme de sécurité reconfigurable 21.

Dans l'exemple précédent considéré, l'opération de reconfiguration est, par exemple, une modification ou un changement des algorithmes de chiffrement et de signature.

La prise de décision est, notamment, réalisée en comparant le niveau de sécurité déterminé lors des étapes 31 à 34 au niveau courant (c'est- à-dire en cours juste avant la prise de décision) de la sécurité de l'application, et la reconfiguration consiste par exemple à sélectionner un algorithme de chiffrement plus ou moins robuste, ou comportant une longueur de clé plus ou moins importante.

Par exemple, on peut avoir une séquence d'opérations du type: Si niveau_de_sécurité_courant > niveau_actuel_de_sécurité alors

// On augmente la sécurité du système Algorithme_crypto = AES

Longueur_de_clé = 128 bits Reconfigure (Algorithme _crypto, Longueur_de_clé) Si niveau_de_sécurité_courant < niveau_actuel_de_sécurité alors

// On relâche la sécurité du système Algorithme_crypto = DES

Longueur_ de__clé = 56 bits Reconfigure (Algorithme_crypto, Longueur_de_clé) L'étape 35 est suivie de l'étape 36 au cours de laquelle on opère la reconfiguration au moyen du mécanisme de sécurité reconfigurable 21. Comme décrit précédemment, une fois la décision prise, lors de l'étape 35, de déclencher l'opération de reconfiguration, cette opération est réalisée, notamment en reconfigurant le système cryptographique à partir d'une

composition différente de modules issus de la même bibliothèque cryptographique, ou bien en téléchargeant dans le terminal de l'utilisateur un nouveau composant cryptographique fournissant des algorithmes plus ou moins robustes ou comportant des longueurs de clé plus ou moins importantes. Considérons un second exemple d'application illustré en Figure 4 dans lequel on réalise une opération d'adaptation de la sécurité de l'application dans un environnement résidentiel. Ainsi, dans cet exemple, on accorde l'accès à un certain nombre de services informationnels en réseau, non pas sur la base d'une identification ou d'une authentification traditionnelle par mot de passe, mais sur la base de la localisation des personnes souhaitant utiliser ces services.

Pour ce faire, des périmètres de sécurité physique correspondant à un bâtiment sont définis, à l'intérieur desquels la sécurité informationnelle peut être relâchée du fait de l'existence d'une sécurité physique traditionnelle, notamment par un contrôle d'accès selon un autre moyen.

L'objectif est donc de ne pas imposer une étape d'authentification qui serait dans ce cas redondante avec la sécurité physique. En effet, on suppose que les personnes autorisées à entrer à l'intérieur de ces périmètres sont des personnes de confiance, et on leur donne accès à un certain nombre de services spécifiques de la maison sans leur imposer une authentification supplémentaire.

Ces personnes non identifiées n'auront cependant pas accès pour autant à tous les services du bâtiment, certains de ces services étant réservés aux habitants habituels du bâtiment qui seraient identifiés par un moyen adéquat nécessitant, par exemple une identification biométrique.

Ce cas d'application est transposable d'un environnement résidentiel à tout lieu recevant des visiteurs "contrôlés" comme un hôtel, un local d'association, voire un local de bureau, et qui donnerait implicitement accès à un certain nombre de services pour les visiteurs authentifiés par leur localisation.

Ainsi, l'authentification par mot de passe demandée sur un réseau, par exemple un réseau de type WLAN ou réseau local sans fil (« Wireless Local

ârea Network » en terminologie anglo-saxonne), peut être remplacée par un certificat de localisation authentifié de manière à interdire aux personnes situées à l'extérieur du périmètre sécurisé d'accéder aux services offerts aux visiteurs légitimes. Cependant, les personnes situées à l'extérieur du périmètre sécurisé pourraient avoir accès à ces mêmes services en utilisant un moyen d'authentification traditionnel par mot de passe ou autre.

Toutefois, si ces personnes ne connaissent pas le mot de passe et cherchent à avoir tout de même accès à ces services en prétendant qu'ils sont à l'intérieur alors qu'ils n'y sont pas, l'usurpation de localisation, notamment par falsification d'une source de localisation, leur serait interdit par un mécanisme d'authentification de la localisation.

En outre, il est possible de réaliser des adaptations complémentaires de cette sécurité fondée sur la localisation. En effet, par exemple, si l'on considère un réseau à périmètre limité par construction tel qu'un réseau d'infrarouge diffusé, qui ne peut pas traverser les murs, on peut tenir compte du fait que les fenêtres sont ouvertes ou non pour adapter la sécurité. Ainsi, il n'est pas nécessaire de demander une localisation complémentaire pour l'authentification lorsque les fenêtres sont fermées, alors que l'on utilisera un réseau radio aussi appelé RFID (authentification par technologie de localisation complémentaire) lorsque les fenêtres sont ouvertes.

L'architecture précédemment décrite est réalisable à l'aide d'une infrastructure logicielle ou matérielle fournissant des informations agrégées de localisation, et plus généralement de contexte physique, à partir de données issues d'un réseau de capteurs. Quant au moteur d'inférence, une mise en œuvre est possible en utilisant le langage de programmation logique Prolog comme traducteur de données de contexte physique en informations de contexte de sécurité, par exemple, des degrés de confiance, en représentant ces informations dans des ontologies appropriées. Le service d'authentificatîon d'informations de contexte est apte à être réalisé à l'aide d'une infrastructure de gestion des privilèges (PMI), le contexte de sécurité étant stocké dans des

certificats d'attributs transmis sur des canaux sécurisés. Dans le cas du contrôle d'accès, le service de sécurité reconfigurable est apte à être mis en œuvre sur terminal mobile ou PDA à l'aide de technologies à composants facilitant l'insertion dynamique de nouvelles classes de politiques de sécurité à appliquer dans le système.

Il est maintenant décrit un système de gestion de contexte 22 ainsi que les différents types de métadonnées pouvant être associées par le service d'authentification d'information de contexte 25 pour qualifier la confiance des informations de contexte, voire des données brutes acquises au moyen des capteurs.

On considère le système de gestion de contexte comme étant constitué d'un graphe orienté acycϋque dont les noeuds représentent Ses éléments de calcul qui vont manipuler et transformer les données de contexte et les arcs ou liens représentent les flux d'information entre ces nœuds. Selon ce graphe, illustré en Figure 5, on distingue trois catégories de nœuds représentées.

Tout d'abord, les producteurs ou sources de contexte 51 sont aptes à produire un ou plusieurs types de données de contexte liées à l'environnement ambiant. Il s'agit typiquement de capteurs permettant d'acquérir des données sur le contexte physique, à savoir, par exemple, la température, la pression, la localisation. Ces données sont les informations de contexte de plus bas niveau d'abstraction manipulées par le système de gestion de contexte.

Ensuite, les consommateurs de contexte 52 sont notamment des modules intervenant dans les applications cibles, et mettant en œuvre des fonctionnalités particulières qui prennent en entrée un certain nombre de types de données de contexte, qu'ils vont prendre en compte pour l'adaptation de leur traitement en cours dit alors adaptatif ou attentif au contexte. Ces données sont en général des informations de contexte de plus haut niveau dans le système de gestion de contexte.

Enfin, les transformateurs (ou interpréteurs) de contexte 53 prennent en entrée un certain nombre de types de données de contexte, par exemple,

des grandeurs physiques et vont produire en sortie un ou plusieurs autres types d'informations de contexte, par exemple, le type d'activité en cours. Les données de contexte produites sont en général de plus haut niveau que celles fournies en entrée et sont appelées informations de contexte. Ces nœuds vont typiquement réaliser des opérations d'agrégation des données de contexte provenant de producteurs ou de transformateurs de contexte situés en amont. Ils transmettent le résultat de cette opération à des transformateurs ou consommateurs de contexte situés en aval. Ces nœuds cumulent donc les fonctions de producteur et de consommateur de contexte. La structure du système de gestion de contexte peut être décrite dans une ontologie dite structurelle incluant notamment les nœuds, les liens et les données de contexte, ainsi que les producteurs, les consommateurs et les interpréteurs de contexte.

En outre, chaque nœud possède une identité qui sert notamment à caractériser les relations de confiance entre les nœuds du système.

Conformément à l'invention, une ontologie structurelle est maintenant décrite en référence à la Figure 6.

A chaque information de contexte manipulée par le système de gestion de contexte est associée un certain nombre de métadonnées décrivant la confiance que l'on peut avoir dans cette information. Ces métadonnées peuvent également être associées à chaque nœud du système pour qualifier la confiance que l'on peut avoir dans le processus de traitement de l'information de contexte réalisé par ce nœud.

Ces métadonnées permettent la construction d'une réputation concernant une information de contexte ou le processus de traitement de cette information. Cette réputation comprend différentes dimensions qui sont autant de manières différentes de qualifier la confiance dans une information de contexte ou son traitement. Les relations entre ces dimensions, dont le nombre peut être étendu, sont décrites à l'aide d'une ontologie dite "de confiance". Cette ontologie peut aussi être étendue pour enrichir la description de cette réputation.

Selon un mode de réalisation, l'ontologie de confiance comprend les éléments illustrés en Figure 7,

Tel qu'illustré en Figure 7, le concept primitif de cette ontologie est celui de "réputation" qui qualifie la confiance que l'on peut avoir dans une information de contexte ou dans le traitement de cette information qui va être réalisé par un nœud du système de gestion de contexte. La réputation permet d'évaluer la confiance qu'un nœud peut avoir dans ses pairs et celle que l'on peut avoir dans la fiabilité d'une information de contexte. Plus précisément, la réputation est "ce qui est généralement affirmé ou cru à propos des caractéristiques ou de la situation/de l'importance d'une personne ou d'une chose" (« A Survey of Trust and Réputation Systems for Online Service Provision » de A. Jθsang, R. Ismail, et C. Boyd, publié en 2006 dans « Décision Support Systems »), ou est "une mesure dérivée de connaissances directes ou indirectes à partir d'interactions antérieures entre agents, et qui est utilisée pour estimer le niveau de confiance qu'un agent peut placer dans un autre agent" ("A Survey Study on Trust Management in P2P Systems" de C. Ding, C. Yueguo, et C. Weiwei du « Department of Computer Science, School of Computing, National University of Singapore », publié en2005).

La qualification de la confiance peut être affinée en regroupant les dimensions ayant trait à la "sécurité" (« security » en terminologie anglo- saxonne), à la "sûreté" (« safety » en terminologie anglo-saxonne), et à la "protection des données personnelles" (« privacy » en terminologie anglo- saxonne). Une définition de ces termes est maintenant donnée :

- la "sécurité" est l'association des propriétés de confidentialité, d'intégrité, et de disponibilité vis-à-vis des actions autorisées (thèse de Doctorat de V. Nicomette, intitulée "La protection dans les systèmes à objets répartis" de 1996) ;

- la "sûreté" est la propriété d'un système qui permet à ses utilisateurs de placer une confiance justifiée dans le service qu'il leur délivre (V. Nicomette dans sa thèse précitée) ; et

- la "protection des données personnelles" est le fait pour un individu ou une organisation de contrôler la collecte, le stockage, le partage, et

la dissémination de données personnelles ou ayant trait à cette organisation (document de M. Abrams, S. Jajodia, et H. Podeil intitulé "Information Security: An Integrated Collection of Essays", et publié en 1995 par IEEE Computer Society Press). A ces dimensions, il faut ajouter la "contextualité", notion qui ne rentre pas directement dans la définition de la réputation, mais qui sert à caractériser le caractère plus ou moins secondaire des informations de contexte. Elle mesure le degré de rapprochement du contexte avec la fonction primaire de l'application / du système, allant d'une donnée de contexte inutile ou redondante jusqu'à une information incontournable à prendre en compte par le système.

Dans la qualification sécuritaire de la confiance, on retrouve les concepts classiques de "confidentialité", "d'intégrité", "d'authenticité", de "non- répudiation", et de "disponibilité". Une définition de ces termes est maintenant donnée :

- la "confidentialité" est la non-occurrence ou la prévention de la divulgation non autorisée de l'information ; plus précisément, "la confidentialité peut être définie comme la capacité d'un système informatique à empêcher la divulgation d'informations, c'est-à-dire à faire en sorte que les informations soient inaccessibles (ou incompréhensibles) pour les utilisateurs non désignés comme autorisés pour y accéder" (Y. Deswartes dans le document "Construction des systèmes d'exploitation répartis", publié dans la Collection Didactique de l'INRIA en 1991 ) ;

- "l'intégrité" est la non-occurrence ou la prévention d'altérations inappropriées de l'information (V. Nicomette dans sa thèse précitée) ; plus précisément, "l ^' intégrité peut être définie comme la capacité du système informatique à empêcher la corruption des informations par les fautes accidentelles ou intentionnelles" (Y. Deswartes dans le document "Construction des systèmes d'exploitation répartis", publié dans la Collection Didactique de l'INRIA en 1991 ) ;

- "l'authenticité" est "le fait de ne pas permettre, par la voie de modifications autorisées, une perte du caractère complet et juste de

l'information" ("Glossaire: Termes relatifs à la sécurité des systèmes d'information" du DCSSI publié à l'adresse suivante : http://www.ssi.gouv.fr/fr/glossaire/index.html) ;

- la "non-répudiation" est "la caractéristique d'un système de cryptographie empêchant un émetteur de pouvoir nier ultérieurement avoir envoyé un message ou exécuter une certaine action" (M. Kaeo dans le livre "Sécurité des réseaux" publié en 2000 par CISCO Press) ; et

- la "disponibilité" est le fait pour un système d'être prêt à l'utilisation (thèse de V. Nicomette). Dans la qualification de la confiance en termes de sûreté, on trouve la notion de "fiabilité", mais aussi celles de "criticité", de "précision", et de "vagosité". Une définition de ces termes est maintenant donnée :

- la "fiabilité" est "l'un des attributs de la sûreté de fonctionnement. Elle correspond à la continuité du service que le système doit fournir à ses utilisateurs, le système étant considéré comme non réparable" (Centre d'Etudes de la Navigation Aérienne dans le "Glossaire de la sûreté de fonctionnement" publié à l'adresse suivante : http://www.tls.cena.fr/divisions/SDF/) ;

- la "criticité" ou risque est "une mesure d'un danger exprimée en fonction de l'occurrence d'un événement indésirable (probabilité, fréquence) et d'une mesure de ses effets ou de ses conséquences [...] Une échelle de risque est souvent associée au danger afin de pouvoir les classer en niveaux de criticité" (Centre d'Etudes de la Navigation Aérienne dans le "Glossaire de la sûreté de fonctionnement" publié à l'adresse suivante : http://www.tls.cena.fr/divisions/SDF/); - la "précision", par exemple d'un capteur, est le fait de pouvoir, lors d'utilisations répétées sans mises à jour, reproduire la même valeur ou mesure, étant données les mêmes conditions et le même environnement d'utilisation (« Alliance for Télécommunications Industry Solutions » dans le glossaire "Telecom Glossary 2000" publié par l'American National Standard sous la référence T1.523-2001 ) ; et

- la" vagosité" est la caractérisation de la donnée de contexte selon les termes de la logique floue (« crisp vs. fuzzy » en terminologie anglo-

saxonne) ; une grandeur « crisp » correspond à une valeur numérique traditionnelle ; au contraire, une grandeur floue associe à la valeur numérique un degré d'appartenance (entre 0 et 1) à un ensemble appelé ensemble flou.

Dans la qualification de la confiance en termes de protection de données personnelles, on trouve la notion de "confidentialité", mais surtout celle de "nymité" (« nymity » en terminologie anglo-saxonne), qui mesure le degré d'anonymat lié à une information de contexte. On peut la définir comme la quantité d'information qui est révélée à propos de l'identité des participants à une transaction. Elle comprend différents niveaux tels que "l'identifiabilité", le "pseudonymat", "l'anonymat", et la "traçabilité". Une définition de ces termes est maintenant donnée en référence au document de A. Pftizmann, M. Hansen, intitulé "Anonymity, Unlikability, Unobservability, Pseudonymity, and Idenîity Management — A Consolidated Proposai for Terminology", de la Technical University of Dresden, publié en 2005 et accessible à l'adresse suivante : http://dud.inf.tu-dresden.de/Anon_Terminology.shtml :

- "l'identifiabilité" est le fait pour un sujet d'être parfaitement identifiable par ses actions ;

- le "pseudonymat" est le fait d'utiliser un pseudonyme pour être identifié, l'anonymat est le fait de ne pas pouvoir être identifiable parmi un ensemble de sujets, dit ensemble d'anonymat ; et

- la "non-traçabilité" (« unlinkability » en terminologie anglo- saxonne) est le fait pour un utilisateur de pouvoir accéder de manière multiple à des ressources ou des services sans que les autres entités faisant parties du système puissent établir des relations entre ces utilisations. Les éléments de l'ontologie de confiance et ceux de l'ontologie structurelle entretiennent les relations illustrées en Figure 8.

Par exemple, la notion de criticité peut s'appliquer à des consommateurs ou des producteurs de contexte (et donc a fortiori aux nœuds intermédiaires). La précision, la vagosité, la fiabilité, la confidentialité, l'authenticité, l'intégrité, et la non-répudiation sont des caractéristiques des informations de contexte. Toutefois, ces caractéristiques peuvent aussi qualifier les nœuds du

système en termes de fiabilité, d'authenticité, ou de confidentialité. Nœuds, liens, et éventuellement informations de contexte possèdent des identités.

Enfin, la contextualité peut s'appliquer aux liens du système de gestion de contexte. Conformément à l'invention, le couplage entre la gestion de la réputation et le système de gestion de contexte proprement dit est permis.

Une architecture de mise en œuvre logicielle et / ou matérielle d'un nœud de gestion de contexte est constituée des éléments décrits ci-dessous et illustrée en Figure 9. Ici, chaque nœud producteur, transformateur, ou consommateur de contexte est, par exemple, constitué des éléments maintenant décrits.

Tout d'abord, cette architecture comprend, notamment, un composant dit de base 91. Ce composant est apte à réaliser le traitement qu'effectuerait le nœud du système de gestion de contexte sans prendre en compte la gestion de la réputation. Ainsi, il prend en entrée un certain nombre d'entrées de contexte provenant d'autres nœuds transformateurs ou producteurs de contexte, et produit en sortie un certain nombre de sorties de contexte à destination de transformateurs ou de consommateurs de contexte.

Ensuite, l'architecture comprend un composant dit de gestion de la réputation 92 pour chaque dimension d de la réputation décrite dans les termes de l'ontologie de qualification de la confiance, d étant, par exemple, la précision, la fiabilité ou la sécurité. Ces composants effectuent des traitements spécifiques à la manipulation des métadonnées décrivant chaque dimension de la réputation. On obtient alors, par exemple, des composants de gestion de la réputation-précision 93, de la réputation-sécurité 94, de la réputation-criticité 95, de la réputation-fiabilité.

Cette architecture d'un nœud de gestion de contexte, illustrée en Figure 9, est ouverte et reconfigurable. Ainsi, le nombre des dimensions décrivant la réputation n'étant pas limitatif, il est ainsi possible d'étendre le comportement d'un nœud de gestion de contexte afin de gérer des dimensions additionnelles d'. Cette opération est effectuée en insérant un nouveau composant de gestion de la réputation. Il est aussi possible de modifier le

traitement d'une dimension donnée d en effectuant le remplacement du composant de gestion de la réputation par un autre effectuant les nouveaux traitements sur les métadonnées correspondant à la dimension d.

La dimension d étant fixée, les composants de gestion de la réputation pour cette dimension d communiquent selon des canaux spécifiques suivant un modèle pair-à-pair, de manière similaire à une infrastructure classique de gestion de la confiance, tel qu'illustré en Figure 10.

Chaque composant de réputation est responsable de la mise à jour des métadonnées concernant la réputation, à la fois pour chaque nœud et/ou pour chaque arc selon le choix de d.

Plus précisément, pour certaines valeurs de dimension d, ces métadonnées ne concernent que les arcs, par exemple les valeurs de confiance entre deux nœuds, tandis que pour d'autres, les métadonnées sont applicables aux nœuds eux-mêmes, par exemple, la criticité. Cette architecture permet le support de plusieurs protocoles de mise à jour, et donc le couplage de l'infrastructure de gestion de contexte avec plusieurs types d'infrastructure de gestion de la confiance (« trust management Systems » en terminologie anglo-saxonne).

Une architecture globale de l'infrastructure maintenant décrite est celle illustrée en Figure 11.

Il est à noter que les informations utilisées par les consommateurs de contexte, notamment les informations issues du système de gestion de contexte, servent d'entrée optionnelles, par rapport au système dans lequel sont intégrés ces consommateurs de contexte. Tel que précédemment décrit, une dimension spécifique de la réputation peut ainsi servir à caractériser le caractère plus ou moins contextuel de ces données.

Cette contextualité est donc un paramètre compris entre 0 et 1 mesurant le degré de rapprochement avec le système principal, 0 correspondant à une donnée de contexte inutile à prendre en compte, 1 à une donnée de contrôle incontournable à prendre en compte par le système principal, c'est-à-dire qui est une entrée primaire du système.

Ce paramètre est notamment issu des consommateurs de contexte et peut être propagé dans l'infrastructure de gestion de contexte en sens opposé des données remontant des producteurs, puisqu'il s'agit d'une contrainte redescendant des consommateurs vers les producteurs. Elle peut, en effet, conditionner le traitement des données de contexte, mais aussi celui des autres dimensions de métadonnées tel que décrit ci-après.

En outre, il est à noter qu'un autre plan spécifique de réputation peut permettre de prendre en compte le fait qu'il s'agit d'un contexte physique.

Ainsi, les attributs de contexte ne prennent pas des valeurs quelconques, mais sont encadrées par les lois de la physique.

Ces spécificités peuvent être décrites sous forme de contraintes ou de distributions de probabilités sur ces attributs, individuellement, par exemple, les valeurs prises par une pression atmosphérique en atmosphère libre, ou reliant ces différents attributs, par exemple, les lois des gaz parfaits reliant la pression avec la température.

Une dimension de métadonnée peut ainsi caractériser la conformité de ces métadonnées par rapport aux contraintes physiques et permettre d'en valider l'utilisation par les étages inférieurs de l'infrastructure.

Enfin, il est à noter que les différentes dimensions de la réputation peuvent être hiérarchisées et privilégiées selon l'application afin de déterminer quelles sont les éléments contextuels à prioriser pour la prise en compte par le système.

Par exemple, dans un contexte applicatif demandant un haut niveau de protection de données personnelles, la priorité peut-être donnée à la réputation-nymité par rapport à la réputation-sécurité. Cela implique un niveau général de divulgation de l'information plus faible, pouvant aller jusqu'à un anonymat complet sans traçabilité. De même, la quantité d'information dont disposent les nœuds de l'infrastructure de gestion de contexte pour établir et mesurer des relations de confiance entre eux est plus faible. La gestion de la réputation-sécurité sera donc dans ce cas moins précise.

II est maintenant décrit un mode de réalisation du système de gestion de contexte. Ainsi, une architecture de réalisation est illustrée en Figure 12.

Selon ce mode de réalisation, les sources de contexte ainsi que les interpréteurs de contexte sont réalisés comme des composants {appelés « bundles » en terminologie anglo-saxonne) implémentant une interface Java, décrite ci-après, appelée « iContextSource » référencée CSI et s'exposant aux applications consommatrices de contexte ou d'autres interpréteurs de contexte comme des services web. Une bibliothèque appelée « ExBindEv library » est également utilisée pour la mise en œuvre des mécanismes exposant ces composants en tant que service web.

L'interface « IContextSource » référencée CSI est constituée notamment des trois méthodes décrite ci-après. Tout d'abord, la méthode « query ( String sparql_str) » permet à une application cliente ou à un interpréteur de contexte d'interroger la source de contexte sur une valeur particulière ou un ensemble de valeurs d'information de contexte.

Ensuite, la méthode « subscribe ( String sparqlevent str, String URL) » permet à la source de contexte d'enregistrer dans une liste, l'intérêt d'une application cliente ou d'un interpréteur de contexte pour une requête sur l'élément d'information de contexte particulier, afin de l'informer ultérieurement dès que la réponse à cette requête change.

Enfin, la méthode « unsubscribe ( String URL) » permet à la source de contexte de dés-enregistrer l'application cliente ou l'interpréteur de contexte de la liste précédente.

En outre, un composant nommé « ContextBroker » permet à des applications consommatrices de contexte de découvrir les sources de contexte et interpréteurs de contexte qui l'intéressent par le biais d'une interface appelée « CBDI », si ces derniers se sont enregistrés auprès du composant

« CcntextBroker ».

Cet enregistrement est réalisé en utilisant par exemple une interface appelée « CBRI » décrite ci-après.

L'interface « CBDI » comprend la méthode

« discoverContextSource ( String context lnf oDesc j » , qui permet à une application de découvrir une source de contexte sur la base d'une description de ses besoins en termes de nature de contexte souhaitée, par exemple la température ambiante, mais également en termes de qualité de l'information, par exemple la précision de la mesure de température. Cette méthode retourne la liste des identifiants des sources de contexte satisfaisant ces besoins.

L'interface « CBRI » est constituée des deux méthodes suivantes. Toute d'abord, cette interface comprend la méthode « registerContextSource ( Striπg contextlnfoDesc , String cSRef ) », qui permet à une source de contexte de se déclarer auprès du composant ContextBroker en lui fournissant une description de ses capacités dans les mêmes termes que ceux utilisés pour la méthode « discoverContexrSource » décrite ci-dessus, ainsi que son identifiant qui permettra aux applications de se connecter à la source de contexte.

En outre, l'interface « CBRI » peut comprendre la méthode « deregisterContextSource (String cSRef ) », qui permet à une source de contexte de se retirer de la liste des sources de contexte maintenue par le composant ContextBroker.

La représentation des besoins et capacités utilisée dans le paramètre contextlnfcDesc des méthodes discoverContextSource et registerContextSource s'appuie sur le langage appelé RDF (« Resource Description Format » en terminologie anglo-saxonne). Le langage RDF permet un formalisme flexible et d'une grande flexibilité qui permet de représenter des informations hétérogènes en grande quantité si besoin. La représentation peut s'exprimer sous forme d'un document texte en XML. De retour à l'exemple précédemment décrit en référence à la

Figure 4, l'authentification doit pouvoir tenir compte également de la plus ou

moins grande sécurité / sûreté du mécanisme de localisation utilisé ainsi que de sa précision.

Par exemple, si l'on utilise un réseau à périmètre limité par construction comme un réseau d'infrarouge diffusé qui ne peut pas traverser les murs, on peut considérer que dans un local sans fenêtre la sécurité et la précision d'une localisation fondée sur la connexion à ce réseau est parfaite. En revanche, si un tel local a des fenêtres ouvertes, une telle technologie n'est plus entièrement sûre et la "réputation" correspondante va s'en trouver modifiée.

Ainsi, le contrôle d'accès réalisé nécessite une très forte sécurité et sûreté de la localisation utilisée par l'application. Ce degré de sûreté / sécurité doit pouvoir lui être fourni en temps réel pour être adapté à son comportement selon la situation. En effet, si la sécurité n'est plus suffisante par rapport aux exigences de l'application, l'application peut revenir à l'utilisation d'une méthode d'authentification traditionnelle et ne plus se contenter de la localisation comme moyen d'authentification.

En termes de précision, il s'agit d'une précision de type ensembliste, qui n'est pas nécessairement homogène dans l'espace. En effet, il est nécessaire d'assurer que la personne se trouve bien à l'intérieur du périmètre sécurisé, mais sans avoir besoin de connaître sa localisation exacte à l'intérieur de ce périmètre. Cette précision pourrait être caractérisée par une fonction d'appartenance de type flou (« fuzzy » en terminologie anglo-saxonne).

Lorsque cette fonction d'appartenance s'éloignerait trop d'une fonction rectangulaire (« crisp » en terminologie anglo-saxonne) et laisserait ainsi une incertitude sur les bords de l'ensemble sécurisé, par exemple tel que décrit plus haut concernant des fenêtres ouvertes avec la localisation infrarouge, l'application peut également en tenir compte.

Par exemple, lors de l'ouverture des volets du local sécurisé, il y a altération de la précision ensembliste. Ainsi, cette situation nécessite une reconfiguration du système de gestion de contexte en choisissant une autre méthode d'authentification plus forte, tel qu'illustré en Figure 13.

De même, dans le cas où une attaque est détectée contre le système de localisation utilisé, par exemple, une attaque par usurpation

("spoofing" en terminologie anglo-saxonne) sur tes données de localisation, il y a altération de la réputation-sécurité. Cette situation nécessite alors une reconfiguration du système de gestion de contexte en choisissant une autre méthode de localisation offrant des garanties de sécurité plus forte, tel qu'illustré en Figure 14»

Selon un second exemple de réalisation, un utilisateur interagit avec des services sur la base de sa propre localisation, qui sert donc d'entrée au système à la place de ce que serait une position de souris dans une interface graphique traditionnelle. Cette localisation peut être utilisée pour différents types d'adaptation.

Par exemple, dans une fonctionnalité d'interface fondée sur la proximité physique, il peut s'agir d'un changement de "focale" de la communication si la personne se rapproche d'un dispositif d'interface pour faire passer d'une communication "grand-angle" à une communication plus focalisée.

En outre, dans une fonctionnalité d'interface appelée en terminologie anglo-saxonne « follow-me », un service suivrait la personne sur le dispositif d'interface le plus proche.

Ainsi, contrairement au cas précédent, les exigences de l'application en termes de sécurité sont très faibles s'agissant d'applications non-critiques.

En revanche, les exigences en termes de précision peuvent être beaucoup plus fines. Il s'agit ici de précision homogène qui serait typiquement caractérisée par un intervalle sur des coordonnées cartésiennes.

Un autre paramètre pouvant qualifier la localisation est dans ce cas le fait qu'une cible puisse être identifiée de manière unique.

Par exemple, dans le cas de localisation fondée sur une technologie de type vision, une cible peut se dédoubler ou être confondue avec une autre dans le cas d'une occlusion. La réputation de fiabilité de celé source de localisation est dans ce cas dégradée et l'application en tiendrait compte. Ainsi, cela amènerait, le cas échéant, l'application à faire appel à une technologie complémentaire pour lever l'ambiguïté sur la localisation introduite par cette technologie. Ceci peut être l'agrégation d'une technologie de

localisation WiFi et d'une technologie de localisation basée vision, qui permettrait de lever l'ambiguïté existante sur la seule localisation fondée sur la vision, tel qu'illustré en Figure 15.

De la même manière, dans le cas d'une localisation fondée sur la radio, comme la technologie connue sous la terminologie anglo-saxonne

« fingerpήnting WiFi », l'existence de perturbations électromagnétiques peut dégrader le degré de précision de cette source de localisation, et l'application pourrait en tenir compte.

Cet exemple peut être généralisé notamment à toutes les applications de communication dans les espaces intelligents ("smart spaces" en terminologie anglo-saxonne) intégrant une instrumentation pour l'acquisition de données de contexte.

En outre, l'invention peut être appliquée notamment à l'assistance contextuelle dans les espaces intelligents, par exemple, à l'assistance ambiante dans les activités de la vie quotidienne.