EP2097878A2 - Procede et dispositif d'adaptation au contexte physique d'une application mettant en oeuvre des mecanismes de securite reconfigurables - Google Patents

Procede et dispositif d'adaptation au contexte physique d'une application mettant en oeuvre des mecanismes de securite reconfigurables

Info

Publication number
EP2097878A2
EP2097878A2 EP07871991A EP07871991A EP2097878A2 EP 2097878 A2 EP2097878 A2 EP 2097878A2 EP 07871991 A EP07871991 A EP 07871991A EP 07871991 A EP07871991 A EP 07871991A EP 2097878 A2 EP2097878 A2 EP 2097878A2
Authority
EP
European Patent Office
Prior art keywords
context information
application
context
security
determined
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP07871991A
Other languages
German (de)
English (en)
Inventor
Marc Lacoste
Gilles Privat
Fano Ramparany
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of EP2097878A2 publication Critical patent/EP2097878A2/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2111—Location-sensitive, e.g. geographical location, GPS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security

Definitions

  • the present invention relates to a method and a device for adapting the security level of an application according to the physical environment in which at least a part of the application runs.
  • the invention relates to ambient intelligence environments that require that the security of the applications is adapted to adapt to particular environmental conditions.
  • the complexity and heterogeneity of these environments introduces many vulnerabilities giving rise to new security requirements.
  • Physical context refers to the physical environment in which at least part of the application runs; this context is, in particular, that of the main user of the application. According to a method described in the document entitled "Cerberus: A
  • security policies in particular in terms of authentication and access control, defining different levels security, take into account contextual information, especially for the physical context.
  • This contextual information is obtained by means of a context management infrastructure.
  • this method can only manage one type of context data, that relating to the location. In addition, it limits itself to a single way of describing the confidence that one can have in these data, being limited to the authentication of the data of context to qualify this confidence.
  • this method does not disclose the adaptation of the security mechanisms of the system based on these context data.
  • the invention aims to remedy at least one of the disadvantages of the prior art by proposing a dynamic adaptation method of an application implementing security mechanisms, characterized in that it comprises the following steps: - determination at least one context information of the physical environment in which at least part of the application runs; determining a security level according to said at least one determined context information;
  • the present invention automatically adapts security policies and mechanisms used in an ambient intelligence environment based on context information about the physical environment in which the application is running, including the environment. of the user.
  • the invention establishes a stronger link between the security level of the application and the physical environment detected, for example by networked sensors in ambient intelligence environments, so as to make it possible to adapt the mechanisms from security to physical context.
  • the application undergoes a dynamic reconfiguration, including security mechanisms, depending on the state of the determined environment, for example by sensors.
  • a dynamic reconfiguration including security mechanisms, depending on the state of the determined environment, for example by sensors.
  • the dynamic adaptation of the security of an application to a physical context can go as far as a complete reconfiguration of the security mechanism, notably by adding or removing features in the application, for example by introducing new security components.
  • the step of determining at least one context information of the physical environment comprises at least one contextual data acquisition step.
  • the acquisition of the contextual data is carried out directly from the physical environment, for example by means of sensors present in the physical environment.
  • the method comprises a step of authenticating said at least one context information.
  • the adaptation of the security of the application depends on the level of authentication of the context information.
  • the authentication of context information also makes it possible to lighten the security mechanisms, taking into account, for example, physical protection devices already present in the environment.
  • the method comprises a step of associating at least one degree of confidence with said at least one determined context information.
  • the decision step is furthermore a function of said at least one degree of confidence associated with said at least one determined context information.
  • the security level of the application is updated by reconfiguration based on the reliability of the context information.
  • the adaptation of the security of an application to a low security level can only take place on the basis of context information whose reliability is sufficient.
  • said at least one degree of confidence is defined according to an ontology.
  • the ontology defines at least one rule for processing said at least one associated context information.
  • the method comprises a step of building a reputation for at least one context information determined according to said at least one degree of confidence associated with said at least one context information determined.
  • said reputation comprises a plurality of dimensions, each dimension being a degree of confidence that qualifies confidence in the context information or its processing.
  • said reputation includes at least one relationship between the qualification dimensions of the trust.
  • an ontology defines the at least one relationship between the qualification dimensions of the trust.
  • the method comprises a step of associating at least one contextuality information with said at least one determined context information qualifying said at least one context information according to its level of importance.
  • the invention also provides a device for dynamically adapting an application implementing security mechanisms, characterized in that it comprises the following means:
  • This device has essentially the same advantages as the method of adapting an application implementing security mechanisms briefly described above.
  • the invention relates to a computer program loadable into a computer system, said program containing instructions for implementing the adaptation method of an application implementing security mechanisms such as discussed above, when this program is loaded and executed by the computer system.
  • the invention also provides a computer program product that can be loaded into a programmable device, characterized in that it comprises an application implementing security mechanisms, means for determining at least one context information of the physical environment in which at least part of the application executes, means for determining a security level according to said at least one determined context information, reconfiguration decision means / no reconfiguration based at least on means of comparison between the determined security level and the current security level applied by the security mechanisms and means for reconfiguring the application to adapt the application to the determined security level.
  • FIG. 1 illustrates a component architecture model
  • FIG. 2 illustrates a software or hardware architecture for adapting the security functionalities of an application according to the physical environment in accordance with the invention
  • FIG. 3 represents an algorithm for adapting the security level of an application according to the invention
  • Figure 4 illustrates an authentication operation based on location information
  • Figure 5 illustrates the nodes of the context management system
  • Figure 6 illustrates a structural ontology for a context management system
  • Figure 7 illustrates a trust qualification ontology
  • Figure 8 illustrates the relationship between trust qualification ontology and structural ontology
  • Figure 9 illustrates an architecture of a context management node
  • Figure 11 illustrates a global context management architecture
  • Figure 12 illustrates an implementation of the context management system
  • FIG. 13 illustrates a location-based access control with an adaptation of the system to a change in the characteristics of this location
  • Figure 14 illustrates location-based access control with prevention of spoofing of location information
  • the security of an application running in an ambient intelligence environment is automatically adapted by dynamic reconfiguration of the application according to policies and security mechanisms used in that environment. This adaptation is performed based on information about the state of the environment in which at least part of the application runs.
  • the environment conditions conditions, according to the invention, the physical context in which runs at least part of the application.
  • the physical context is determined from information acquired through sensors distributed in the environment.
  • the sensors are able, for example, to determine the position of the user, and more generally the relevant elements of the context in which the user is (alone in an office, in a meeting, engaged in a non-interruptible activity, and so on. right now).
  • the physical context can be managed by means of a context management system.
  • the adaptation of the application can also be performed according to the level of confidence of the contextual information obtained.
  • adapting the security of an application to a lower level of security can only be done based on contextual information about which one can have a sufficient degree of confidence, and whose authenticity is assured.
  • the purpose of adjusting the security level of an application is to provide "just enough" protection, without overloading the user with oversized, redundant, or unsuitable security mechanisms.
  • the security of the application is adapted to, or even associated with, the security of the physical protection devices that exist elsewhere in the user's environment.
  • the authentication process of the application can be alleviated if the user is present in a premises whose access is already protected by a traditional physical security mechanism, for example, a lockable door or a biometric security device.
  • the contextual information determined in particular by means of the sensors, for example the nature of the activity in progress, are used to trigger an adaptation of the security mechanisms of the application, if necessary. It is thus possible to automatically select the security level of the application adapted to its proper functioning, without unnecessarily overloading the user's attention by asking, for example, its approval for each operation of adaptation of the level of security of the application.
  • these are designed according to an approach based on software components as illustrated in Figure 1.
  • the software components are defined as entities encapsulating code and data that appear in software systems as threads, configuration / reconfiguration, deployment, or administration.
  • An application designed according to a component model makes it possible to control the complexity of implementation of the software infrastructure, since the components can themselves be composed to form high-level code units.
  • An application designed according to a component model also allows flexibility in the chosen configuration since the functionality of the application can be adapted or introduced by adding or replacing components in the application.
  • an application is reconfigurable and thus makes the choice of components flexible.
  • a component is an executable entity built from a controller that oversees its execution.
  • a composite component is like a white box in which components, called primitive components, are interconnected. These primitive components are considered black boxes. Indeed, they encapsulate the software code.
  • a component can only interact with its environment through a set of well-defined access points called interfaces. The interactions between the components require the establishment of links between the interfaces of these components.
  • Figure 2 illustrates a software architecture and / or hardware adaptation of an application according to its physical execution environment according to the invention.
  • This architecture includes a flexible security service 21 adapted to allow the adaptation of the security mechanism or the security level of an application, then an acquisition infrastructure, aggregation and context management 22 called below "Context management system", an inference engine 23 of the security context from the determined physical context and a security service adaptation decision mechanism 24 based on information on the security context.
  • this architecture can also include a context information authentication service 25.
  • this architecture can also include a context information authentication service 25.
  • the adaptation of the security of an application according to the physical context of the user is carried out according to the following process.
  • the distributed or centralized context management system 22 obtains low level context data.
  • This data relates in particular to physical quantities, for example, provided by a network of sensors Ci arranged in the environment in which the application is running.
  • These quantities may be, for example, a temperature, a pressure, a distance from a reference point, a location. These quantities are then aggregated to determine context information of more or less high level, such as, for example, the position or position of the user with respect to a relevant reference system, the state of the environment, the activity within that environment, the situation, the ambient noise level. It is thus possible to infer from the low-level context data, information on the current activities in the environment that will adapt the security of the application running in this environment.
  • An embodiment of the context management system 22 is described hereinafter with reference to Figures 5 to 12.
  • the context information authentication service 25 can associate with the previously determined context information a degree of contextuality which would be for example strictly between 0 and 1, 0 corresponding to useless information and 1 to important information for the context. system.
  • This degree (s) of contextuality can later be taken into account when adapting the security level of the application by the security service 21.
  • qualifying this context information makes it possible to modulate their use for the application. adaptation of the security of an application.
  • the context information is associated with a security degree of confidence provided by the context information authentication service and a reliability degree of confidence. .
  • the context information is "low trust", it will typically not be used for critical adaptations as it could be for security-inconsequential adaptations.
  • This notion of trust or quality of contextual data can take on many aspects. It can be trusted in terms of reliability, accuracy, standard security, privacy (non-spyware), integrity (data not tampered with in a malicious way), or authenticity (a data source is not substituted by another). This trust can also be related to respect for privacy (more or less restricted access to data by third parties).
  • the context information authentication service 25 is able to attach to the context information, or even the raw data acquired, metadata integrating these different confidence dimensions.
  • This metadata can also be modified by taking into account the processing applied to the data throughout their processing and aggregation.
  • the inference engine 23 deduces the appropriate security context Cs.
  • the latter is, for example, the security level for the application adapted to the activity or the current situation of execution of the application in terms of environment.
  • the context information from which the inference engine deduces the current security context can be described in a formal security ontology, and the same is true for information from the inference engine.
  • the appropriate security context Cs is then securely transmitted to the adaptation decision mechanism of the security service 24.
  • This appropriate security context Cs can also be used to adapt the context information authentication service 25.
  • the level of authentication is higher or lower depending on the required level of security. .
  • the decision mechanism 24 triggers or not the reconfiguration or parameterization of the adaptation of the security service 21.
  • the security level is high during communications sent and received by the user's terminal present in a hostile and insecure environment.
  • a hostile environment where the risk of interception of communications is not negligible is, for example, a country at risk or a competing enterprise.
  • the high level of security is achieved, in particular, by the use of a robust encryption algorithm, for example, by means of an algorithm cryptographic type AES or advanced encryption standard ("Advanced Encryption Standard" in English terminology).
  • the security level of the application can be mitigated, particularly in terms of the protection of communications.
  • the security service considered in this example is a cryptographic library used to encrypt and / or sign communications.
  • the application designed according to a component model can undergo a reconfiguration operation in order to change the application to a higher level of security. To do this, the reconfiguration is performed by downloading a new cryptographic library providing algorithms more robust or with longer key lengths.
  • the reconfiguration of an application is performed, for example, according to the steps described below with reference to FIG.
  • the algorithm starts at step 31 consisting of the acquisition of context data from the user's environment, in particular by means of the context management system 22.
  • this step is performed by means of a location determination system which makes it possible to locate the user with respect to a repository, namely the country in which the user is located, the position of the user. the user in relation to an already secure environment, for example, an indoor or outdoor environment of the home, a meeting room, or a business.
  • a location determination system which makes it possible to locate the user with respect to a repository, namely the country in which the user is located, the position of the user. the user in relation to an already secure environment, for example, an indoor or outdoor environment of the home, a meeting room, or a business.
  • this step is performed by aggregating low level information from several location determination systems.
  • the location data thus aggregated and consolidated are then transmitted to the authentication service 25 to ensure their authenticity.
  • Step 31 is followed by step 32 of authenticating the user context, in particular by means of the authentication service 25. During this step, it is ensured that the context data produced during step 31 are authentic, that they were generated by a trustworthy localization infrastructure, and that they were not modified by a malicious third party.
  • step 31 an attribute certificate is generated and signed by the location infrastructure where the attribute of the certificate contains the location information, in step 32, this The last step is to verify the certificate, ensuring that the signature of the location infrastructure is valid.
  • Step 32 is followed by step 33 during which the security context is inferred, in particular by means of the inference engine 23.
  • the inference engine derives the level of security from the environment by comparing the location data provided in steps 31 and 32 to the security level of the application.
  • This policy includes, for example, the rules for using cryptography in the country where the user is located. These rules can be of the form:
  • step 33 is followed by step 34 of securely transmitting the determined security context, i.e. the appropriate current security level, including the decision mechanism 24.
  • step 33 the attribute key_length updated in step 33 is then transmitted securely to the decision mechanism 24, for example, after being encrypted using a symmetric key shared between the engine d. inference and the decision mechanism.
  • Step 34 is followed by step 35 during which the decision to reconfigure or not the application is made, in particular by means of the decision mechanism 24.
  • the decision mechanism 24 makes the decision or not to trigger the reconfiguration operation of the reconfigurable security mechanism component 21.
  • the reconfiguration operation is, for example, a modification or a change of the encryption and signature algorithms.
  • the decision making is, in particular, performed by comparing the security level determined in steps 31 to 34 to the current level (that is, current just before the decision is made) of the security of the application, and the reconfiguration consists for example in selecting a more or less robust encryption algorithm, or having a key length more or less important.
  • Key_Length 128 bits Reconfigure (_crypto Algorithm, Key_Length) If current_security_ level ⁇ current_security_ level then
  • Step 35 is followed by step 36 in which the reconfiguration is performed by means of the reconfigurable security mechanism 21.
  • this operation is performed, in particular by reconfiguring the cryptographic system from a different composition of modules from the same cryptographic library, or by downloading into the user's terminal a new cryptographic component providing algorithms more or less robust or with more or less important key lengths.
  • the goal is not to impose an authentication step that would be redundant in this case with physical security. Indeed, it is assumed that the persons authorized to enter these perimeters are trusted persons, and they are given access to a number of specific services of the house without imposing additional authentication.
  • This application case can be transposed from a residential environment to any place receiving "controlled" visitors such as a hotel, an association room, or even an office space, and which would implicitly give access to a certain number of services for them. visitors authenticated by their location.
  • password authentication requested on a network may be replaced by an authenticated location certificate to prohibit persons outside the secure perimeter from accessing the services offered to legitimate visitors.
  • a network for example a WLAN type network or wireless local area network (“Wireless Local "Network” in English terminology
  • Wired Local "Network” in English terminology
  • password authentication may be replaced by an authenticated location certificate to prohibit persons outside the secure perimeter from accessing the services offered to legitimate visitors.
  • people outside the secure perimeter may be able to access these same services using traditional password authentication or other means.
  • the architecture described above is feasible using a software or hardware infrastructure providing aggregated location information, and more generally physical context, from data from a sensor network.
  • an implementation is possible by using the Prolog logic programming language as a translator of physical context data into security context information, for example, degrees of trust, by representing this information in ontologies. appropriate.
  • the context information authentication service is adapted to be implemented using a privilege management infrastructure (PMI), the security context being stored in attribute certificates passed on secure channels.
  • PMI privilege management infrastructure
  • the reconfigurable security service is able to be implemented on a mobile terminal or PDA using component technologies that facilitate the dynamic insertion of new classes of security policies to be applied in the context of the application. system.
  • context management system 22 As well as the different types of metadata that can be associated by the context information authentication service 25 to qualify the trust of the context information, or even raw data acquired by means of sensors.
  • the context management system is considered to consist of an acyc ⁇ c oriented graph whose nodes represent its computing elements that will manipulate and transform the context data and the arcs or links represent the information flows between these nodes. According to this graph, illustrated in Figure 5, there are three categories of nodes represented.
  • the producers or context sources 51 are able to produce one or more types of context data related to the ambient environment. These are typically sensors for acquiring data on the physical context, eg, temperature, pressure, location. This data is the lowest level abstraction context information handled by the context management system.
  • context consumers 52 are notably modules intervening in the target applications, and implementing particular functionalities that take as input a certain number of types of context data, which they will take into account for the adaptation of context. their current processing then says adaptive or context-sensitive. This data is typically higher level context information in the context management system.
  • the context transformers (or interpreters) 53 input a number of context data types, for example, physical quantities and will output one or more other types of context information, for example, the type of activity in progress.
  • the context data produced is generally higher than that provided at input and is called context information.
  • These nodes will typically perform context data aggregation operations from upstream context producers or transformers. They transmit the result of this operation to downstream transformers or context consumers. These nodes thus accumulate the functions of producer and consumer of context.
  • the structure of the context management system can be described in a so-called structural ontology including nodes, links and context data, as well as producers, consumers and context interpreters.
  • each node has an identity that serves in particular to characterize the trust relationships between the nodes of the system.
  • Each context information manipulated by the context management system is associated with a number of metadata describing the confidence that can be had in this information. This metadata can also be associated with each node of the system to qualify the confidence that can be had in the process of processing the context information made by this node.
  • This metadata allows the construction of a reputation regarding context information or the process of processing this information.
  • This reputation includes different dimensions that are different ways of qualifying trust in context information or its treatment. The relationships between these dimensions, the number of which can be extended, are described using a so-called "trust" ontology. This ontology can also be extended to enrich the description of this reputation.
  • the trusted ontology comprises the elements illustrated in FIG.
  • the primitive concept of this ontology is that of "reputation” which qualifies the confidence which one can have in a information of context or in the treatment of this information which will be realized by a node of the context management system.
  • Reputation can be used to assess the trust that a node can have in its peers and the trust that can be had in the reliability of context information.
  • reputation is "what is generally asserted or believed about the characteristics or situation / importance of a person or thing" ("A Survey of Trust and Reputation Systems for Online Service Provision").
  • the "protection of personal data” is the fact for an individual or an organization to control the collection, storage, sharing, and the dissemination of personal data or data relating to this organization (document by Mr. Abrams, S. Jajodia, and H. Podeil entitled “Information Security: An Integrated Collection of Essays", and published in 1995 by IEEE Computer Society Press).
  • Contextuality a concept that does not fit directly into the definition of reputation, but which serves to characterize the more or less secondary nature of context information. It measures the degree of closeness of the context to the primary function of the application / system, ranging from unnecessary or redundant context data to essential information to be taken into account by the system.
  • confidentiality is the non-occurrence or prevention of unauthorized disclosure of information; more specifically, “confidentiality may be defined as the ability of a computer system to prevent the disclosure of information, that is, to make the information inaccessible (or incomprehensible) to non-designated users as authorized to access it "(Y. Deswartes in the document” Construction of Distributed Farming Systems ", published in the INRIA Didactic Collection in 1991);
  • Integrity is the non-occurrence or prevention of inappropriate alterations of information (see Nicomette in his above-mentioned thesis); more precisely, "the integrity can be defined as the ability of the computer system to prevent corruption of information by accidental or intentional misconduct” (Y. Deswartes in “Construction of distributed operating systems", published in the Collection Didactics of INRIA in 1991);
  • non-repudiation is "the characteristic of a cryptographic system preventing a sender from being able to deny having sent a message or performing a certain action" (Mr. CISCO Press);
  • criticality or risk is "a measure of a hazard expressed as a function of the occurrence of an adverse event (probability, frequency) and a measure of its effects or consequences section
  • the risk scale is often associated with the hazard so that it can be classified into criticality levels "(Air Navigation Studies Center in the" Safety Glossary "published at: http: // www.
  • fuzzy logic crisp vs. fuzzy in English terminology. Saxon; a "crisp” size corresponds to a traditional numerical value; on the contrary, a fuzzy quantity associates with the numerical value a degree of belonging (between 0 and 1) to a set called fuzzy set.
  • the "pseudonymat" is the fact of using a pseudonym to be identified, the anonymity is the fact of not being able to be identifiable among a set of subjects, said set of anonymity;
  • unlinkability is the fact that a user may have multiple access to resources or services without the other entities forming part of the system being able to establish relationships between them. uses.
  • the elements of trust ontology and those of structural ontology maintain the relationships illustrated in Figure 8.
  • the notion of criticality can be applied to consumers or context producers (and therefore a fortiori to intermediate nodes).
  • Precision, vagueness, reliability, confidentiality, authenticity, integrity, and non-repudiation are features of context information. However, these characteristics may also qualify the nodes of the system in terms of reliability, authenticity, or confidentiality. Nodes, links, and possibly context information have identities.
  • contextuality can be applied to the links of the context management system.
  • the coupling between the reputation management and the context management system itself is allowed.
  • a software and / or hardware implementation architecture of a context management node consists of the elements described below and illustrated in FIG. 9.
  • each producer, transformer or context consumer node is, for example, consisting of the elements now described.
  • this architecture includes, in particular, a so-called basic component 91.
  • This component is able to perform the processing that would perform the node of the context management system without taking into account reputation management. Thus, it takes as input a number of context inputs from other transformers or context producers, and outputs a number of context outputs to transformers or context consumers.
  • the architecture includes a reputational management component 92 for each dimension d of the reputation described in the terms of the trust qualification ontology, for example, accuracy, reliability, or security. .
  • These components perform metadata manipulation specific processing describing each dimension of the reputation.
  • the reputation-precision 93, 94 reputation-security, 95 reputation-reputation and reputation-reliability components are obtained.
  • This architecture of a context management node is open and reconfigurable.
  • the number of dimensions describing the reputation is not limiting, it is thus possible to extend the behavior of a context management node to manage additional dimensions of. This is done by inserting a new reputation management component. It is also possible to modify the processing a given dimension d by performing the replacement of the reputation management component with another performing the new processing on the metadata corresponding to dimension d.
  • the reputation management components for this dimension d communicate in specific channels in a peer-to-peer fashion, similar to a typical trust management infrastructure, as shown in Figure 10.
  • Each reputation component is responsible for updating metadata about reputation, for each node and / or for each arc depending on the choice of d.
  • these metadata concern only the arcs, for example the values of confidence between two nodes, while for others, the metadata are applicable to the nodes themselves, for example, criticality. .
  • This architecture allows the support of several update protocols, and thus the coupling of the context management infrastructure with several types of trust management infrastructure ("trust management systems" in English terminology).
  • the information used by the context consumers serves as an optional input, relative to the system in which these context consumers are integrated.
  • a specific dimension of reputation can thus be used to characterize the more or less contextual nature of these data.
  • This contextuality is therefore a parameter between 0 and 1 measuring the degree of reconciliation with the main system, 0 corresponding to an unnecessary context data to be taken into account, 1 to a control data unavoidable to be taken into account by the main system, that is, which is a primary input of the system.
  • This parameter is derived in particular from context consumers and can be propagated in context management infrastructure in the opposite direction of producer data, since it is a downward constraint from consumers to producers. It can, in fact, condition the processing of context data, but also that of the other dimensions of metadata as described below.
  • context attributes do not take any values, but are framed by the laws of physics.
  • a metadata dimension can thus characterize the conformity of these metadata with respect to the physical constraints and make it possible to validate their use by the lower floors of the infrastructure.
  • the different dimensions of the reputation can be prioritized and prioritized according to the application to determine which contextual elements to prioritize for the consideration by the system.
  • the context sources as well as the context interpreters are made as components (called “bundles” in English terminology) implementing a Java interface, described below, called “iContextSource” referenced CSI and s exposing context-consuming applications or other context interpreters such as web services.
  • a library called “ExBindEv library” is also used to implement mechanisms exposing these components as a web service.
  • the "IContextSource” interface referenced CSI consists in particular of the three methods described below.
  • the query (String sparql_str) method allows a client application or context interpreter to query the context source on a particular value or set of context information values.
  • the method “subscribe (String sparqlevent str, String URL)” allows the context source to save in a list, the interest of a client application or a context interpreter for a query on the element particular context information, in order to inform it later as soon as the response to this request changes.
  • ContextBroker allows context-consuming applications to discover context sources and context interpreters that interest it through an interface called “CBDI”, if they have registered with the client.
  • CcntextBroker This recording is performed using for example an interface called “CBRI” described below.
  • the "CBDI" interface includes the method
  • DiscoverContextSource (String context lnf oDesc j" which allows an application to discover a context source based on a description of its needs in terms of the desired context nature, for example ambient temperature, but also in terms of the quality of the information, for example the accuracy of the temperature measurement This method returns the list of context source identifiers satisfying these needs.
  • the "CBRI” interface consists of the following two methods. First, this interface includes the "registerContextSource (Stri ⁇ g contextlnfoDesc, String cSRef)” method, which allows a context source to declare itself to the ContextBroker component by providing a description of its capabilities in the same terms used. for the "discoverContexrSource” method described above, as well as its identifier that will allow applications to connect to the context source.
  • CBRI ContextBroker
  • deregisterContextSource String cSRef
  • the representation of the needs and capacities used in the contextlnfcDesc parameter of the methods discoverContextSource and registerContextSource is based on the language called RDF ("Resource Description Format" in English terminology).
  • RDF Resource Description Format
  • the RDF language allows a flexible and flexible formalism that allows to represent heterogeneous information in large quantities if needed.
  • the representation can be expressed as a text document in XML.
  • the authentication must be able to also take into account the more or less security / safety of the locating mechanism used as well as its accuracy.
  • a constructionally limited perimeter network such as a broadcast infrared network that can not cross walls, it can be considered that in a windowless room the security and accuracy of a location based on the connection to this network is perfect.
  • a constructionally limited perimeter network such as a broadcast infrared network that can not cross walls, it can be considered that in a windowless room the security and accuracy of a location based on the connection to this network is perfect.
  • such a room has open windows, such technology is no longer entirely safe and the corresponding "reputation" will be modified.
  • the access control performed requires a very strong security and security of the location used by the application. This degree of safety / security must be provided to him in real time to be adapted to his behavior according to the situation. Indeed, if the security is no longer sufficient compared to the requirements of the application, the application can return to the use of a traditional authentication method and no longer be satisfied with the location as a means of authentication .
  • this is a set-type precision, which is not necessarily homogeneous in space. Indeed, it is necessary to ensure that the person is well inside the secure perimeter, but without needing to know its exact location within this perimeter.
  • This precision could be characterized by a membership function of fuzzy type ("fuzzy" in English terminology).
  • a user interacts with services on the basis of his own location, which thus serves as an input to the system instead of what would be a mouse position in a traditional graphical interface.
  • This location can be used for different types of adaptation.
  • an interface functionality based on physical proximity, it may be a change in "focal length" of the communication if the person approaches an interface device to move a communication "wide-angle" to a more focused communication.
  • Another parameter that can qualify the location is in this case the fact that a target can be identified uniquely.
  • This example can be generalized in particular to all communication applications in smart spaces ("smart spaces" in English terminology) integrating an instrument for the acquisition of context data.
  • the invention can be applied in particular to contextual assistance in the intelligent spaces, for example, to ambient assistance in the activities of daily life.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)
  • Telephone Function (AREA)

Abstract

L'invention concerne un procédé d'adaptation d'une application mettant en oevre 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é.

Description

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.

Claims

REVENDICATIONS
1. 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é.
2. Procédé d'adaptation selon la revendication 1 , caractérisé en ce que 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.
3. Procédé d'adaptation selon la revendication 1 ou la revendication 2, caractérisé en ce que le procédé comprend une étape d'authentification de ladite au moins une information de contexte.
4. Procédé d'adaptation selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend une étape d'association d'au moins un degré de confiance à ladite au moins une information de contexte déterminée.
5. Procédé d'adaptation selon les revendications 3 et 4, caractérisé en ce que 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.
6. Procédé d'adaptation selon la revendication 4 ou la revendication
5, caractérisé en ce que ledit au moins un degré de confiance est défini selon une ontologie.
7. Procédé d'adaptation selon la revendication 6, caractérisé en ce que l'ontologie définit au moins une règle de traitement de ladite au moins une information de contexte associée.
8. Procédé d'adaptation selon l'une quelconque des revendications 4 à 7, caractérisé en ce qu'il 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.
9. Procédé d'adaptation selon la revendication 8, caractérisé en ce que ladite réputation comprend une pluralité de dimensions, chaque dimension étant un degré de confiance qualifiant la confiance dans l'information de contexte ou de son traitement.
10. Procédé d'adaptation selon la revendication 9, caractérisé en ce que ladite réputation comprend au moins une relation entre les dimensions de qualification de la confiance.
11. Procédé d'adaptation selon la revendication 10, caractérisé en ce qu'une ontologie définit ladite au moins une relation entre les dimensions de qualification de la confiance.
12. Procédé d'adaptation selon l'une quelconque des revendications précédentes, caractérisé en ce que 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.
13. Dispositif d'adaptation dynamique d'une application mettant en oeuvre 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é.
14. Dispositif d'adaptation selon la revendication 13, caractérisé en ce que les moyens de détermination d'au moins une information de contexte de l'environnement physique comprennent des moyens d'acquisition de données contextuelles.
15. Dispositif d'adaptation selon la revendication 13 ou la revendication 14, caractérisé en ce que le dispositif comprend des moyens d'authentification de ladite au moins une information de contexte.
16. Dispositif d'adaptation selon l'une quelconque des revendications 13 à 15, caractérisé en ce qu'il comprend des moyens d'association d'au moins un degré de confiance à ladite au moins une information de contexte déterminée.
17. Dispositif d'adaptation selon les revendications 15 et 16, caractérisé en ce que les moyens de décision sont aptes à décider en outre en fonction dudit au moins un degré de confiance associé à ladite au moins une information de contexte déterminée.
18. Dispositif d'adaptation selon la revendication 16 ou la revendication 17, caractérisé en ce que ledit au moins un degré de confiance est défini selon une ontologie.
19. Dispositif d'adaptation selon la revendication 18, caractérisé en ce que l'ontologie définit au moins une règle de traitement de ladite au moins une information de contexte associée.
20. Dispositif d'adaptation selon l'une quelconque des revendications 16 à 19, caractérisé en ce qu'il comprend des moyens 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.
21. Dispositif d'adaptation selon la revendication 20, caractérisé en ce que ladite réputation comprend une pluralité de dimensions, chaque dimension étant un degré de confiance qualifiant la confiance dans l'information de contexte ou de son traitement.
22. Dispositif d'adaptation selon la revendication 21 , caractérisé en ce que ladite réputation comprend au moins une relation entre les dimensions de qualification de la confiance.
23. Dispositif d'adaptation selon la revendication 22, caractérisé en ce qu'une ontologie définit ladite au moins une relation entre les dimensions de qualification de la confiance.
24. Dispositif d'adaptation selon l'une quelconque des revendications
13 à 23, caractérisé en ce que le dispositif comprend des moyens 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.
25. 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 oeuvre des mécanismes de sécurité selon l'une quelconque des revendications 1 à 12, lorsque ce programme est chargé et exécuté par ledit système informatique.
26. 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é.
EP07871991A 2006-12-29 2007-12-20 Procede et dispositif d'adaptation au contexte physique d'une application mettant en oeuvre des mecanismes de securite reconfigurables Ceased EP2097878A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0656051 2006-12-29
PCT/FR2007/052580 WO2008087331A2 (fr) 2006-12-29 2007-12-20 Procede et dispositif d'adaptation au contexte physique d'une application mettant en oeuvre des mecanismes de securite reconfigurables

Publications (1)

Publication Number Publication Date
EP2097878A2 true EP2097878A2 (fr) 2009-09-09

Family

ID=38261599

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07871991A Ceased EP2097878A2 (fr) 2006-12-29 2007-12-20 Procede et dispositif d'adaptation au contexte physique d'une application mettant en oeuvre des mecanismes de securite reconfigurables

Country Status (2)

Country Link
EP (1) EP2097878A2 (fr)
WO (1) WO2008087331A2 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105447931B (zh) * 2015-03-09 2017-10-24 北京天诚盛业科技有限公司 门禁远程授权的方法、装置和系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020152382A1 (en) * 1999-06-11 2002-10-17 Sihai Xiao Trust information delivery scheme for certificate validation
US20040122704A1 (en) * 2002-12-18 2004-06-24 Sabol John M. Integrated medical knowledge base interface system and method
US20060265324A1 (en) * 2005-05-18 2006-11-23 Alcatel Security risk analysis systems and methods

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6636983B1 (en) * 1999-10-07 2003-10-21 Andrew E. Levi Method and system for uniform resource locator status tracking
US20030191949A1 (en) * 2000-08-30 2003-10-09 Akihiro Odagawa Authentication system, authentication request device, validating device and service medium
US7260555B2 (en) * 2001-12-12 2007-08-21 Guardian Data Storage, Llc Method and architecture for providing pervasive security to digital assets
US7591020B2 (en) * 2002-01-18 2009-09-15 Palm, Inc. Location based security modification system and method
US8359645B2 (en) * 2005-03-25 2013-01-22 Microsoft Corporation Dynamic protection of unpatched machines

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020152382A1 (en) * 1999-06-11 2002-10-17 Sihai Xiao Trust information delivery scheme for certificate validation
US20040122704A1 (en) * 2002-12-18 2004-06-24 Sabol John M. Integrated medical knowledge base interface system and method
US20060265324A1 (en) * 2005-05-18 2006-11-23 Alcatel Security risk analysis systems and methods

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
AL-MUHTADI J ET AL: "Cerberus: a context-aware security scheme for smart spaces", PERCOM '03 PROCEEDINGS OF THE FIRST IEEE INTERNATIONAL CONFERENCE ON PERVASIVE COMPUTING AND COMMUNICATIONS, IEEE, US, 26 March 2003 (2003-03-26), pages 489 - 496, XP032384629, ISBN: 978-0-7695-1893-0, DOI: 10.1109/PERCOM.2003.1192774 *

Also Published As

Publication number Publication date
WO2008087331A3 (fr) 2008-11-06
WO2008087331A2 (fr) 2008-07-24

Similar Documents

Publication Publication Date Title
Ravidas et al. Access control in Internet-of-Things: A survey
Sinha et al. Building an E Ective IoT Ecosystem for Your Business
Sicari et al. Security policy enforcement for networked smart objects
US8659997B2 (en) Policy-based service management system
Barka et al. Securing the web of things with role-based access control
IL269177A (en) Provide core network access
US20150135277A1 (en) Methods for Generating and Using Trust Blueprints in Security Architectures
FR3007551A1 (fr) Procede et serveur de traitement d&#39;une requete d&#39;acces d&#39;un terminal a une ressource informatique
Moghaddam et al. Policy Engine as a Service (PEaaS): An approach to a reliable policy management framework in cloud computing environments
Gabillon et al. Access controls for IoT networks
Kapitsaki Reflecting user privacy preferences in context-aware web services
Sayaf et al. Access control models for online social networks
EP3367290A1 (fr) Systèmes, procédés et produits-programme informatiques pour combiner des technologies d&#39;amélioration de la sphère privée
Zichichi et al. Ensuring personal data anonymity in data marketplaces through sensing-as-a-service and distributed ledger
Di Modica et al. Semantic security policy matching in service oriented architectures
Ksiezopolski et al. Quality of protection evaluation of security mechanisms
Bruno et al. Enforcing access controls in IoT networks
WO2008087331A2 (fr) Procede et dispositif d&#39;adaptation au contexte physique d&#39;une application mettant en oeuvre des mecanismes de securite reconfigurables
Singh Reputation based distributed trust model for P2P networks
Koshutanski et al. Interoperable semantic access control for highly dynamic coalitions
Tran A Systematic Literature Review on Secure IoT Data Sharing
Yaich Trust management systems: a retrospective study on digital trust
Olmedilla Security and privacy on the semantic web
Neisse et al. An information model and architecture for context-aware management domains
Yuan et al. Data centered and Usage-based Security service

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20090702

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

17Q First examination report despatched

Effective date: 20140204

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20190926