Céline Coma

Nora Cuppens-Boulahia

Frédéric Cuppens

Chapter 1 Secure interoperability with O2O contracts

 Furthermore, as interoperation may lead to a lot of exchanges of information before and during the interoperability session, in particular those related to credentials and security policies, we propose to ensure privacy protection to use the O2O licence administrative view and an XML block based access control technique to obfuscate some of the information exchanged.

Introduction

In traditional approaches of data processing and resource access controlling, the model of an organization is rather static. This is sufficient for managing securely the behavior of an organization within settled ranges of actions; it is unsatisfactory when the environment of the organization changes following the occurrence of different events like those generated by interoperability sessions.

Environment changes become an established fact of current organizations. They need to be agile, flexible and securely interoperable since they act in an increasingly dynamic environment which tends to be collaborative but unfortunately possibly hostile. To meet these requirements, synthetic knowledge is needed to let organizations continuously manage accesses, ensure the integrity of exchanges and the continuity of services.

Most of the recent works argue for the use of ontologies as a mean for providing this synthetic knowledge of common domains. Moreover, as this cooperation must be secure for each of the party involved within it, it is necessary to provide a context-aware tailored 1 mapping process that takes into account this security aspect and derives the security policies. We claim that this derivation process needs to use: (1) ontological mapping, this means mapping structure-oriented entities of the two organizations having to interoperate. Accordingly, a correct meaning can be assigned to these structuring entities which could seem a priori different. Examples of these entities are roles or activities pertaining to these organizations, especially the environmental conditions under which they evolve, and (2) compatibility relations between the grantor organization offering the service and the grantee organization requesting an access to the service, this means mapping deonticoriented entities of the organizations having to interoperate. These relations will be used to specify interoperability policies. In this case, deontic entities are primarily permissions and prohibitions rules.

Moreover, these interoperability security policies must not be derived on the fly. This can lead to a lack of fairness, inconsistencies and breaches of security. Also, these policies are usually established after a phase of policy negotiation, which can be time consuming. This lapse of time may in some cases be longer than the interoperability session and result in a loss of efficiency.

In this chapter, we propose an approach to anticipate the definition of interoperability security policies and thus shorten the policy negotiation steps. Our work is based on the O2O approach [START_REF] Cuppens | O2O: Virtual Private Organizations to Manage Security Policy Interoperability[END_REF] as a framework for a secure interoperability where the authority sphere defining security policy and the management sphere administering this security policy are well identified. We define interoperability contracts to control the aforementioned derivation process of security policies. This process is characterized by a duality between the maximization of the security and the insurance of the cooperation.

The rest of this chapter is organized as follows. In section 1.2 we carry out a survey of existing research works related to secure interoperability and emphasize on their weaknesses. In section 1.3 we recall the two basic bricks we use to express, derive and enforce context-aware interoperability policies: the contextual security model OrBAC [START_REF] El Kalam | Organization Based Access Control[END_REF] and the interoperability framework O2O. In section 1.4 we explain the steps for interoperability establishment. After limiting the scope of interoperability in section 1.6, we state formally the different types of compatibility relations between the grantor and the grantee organizations to establish interoperability security policy rules. This formal statement is based on the ontological mapping and the definition of compatibility constraints. The process guarantees that the interoperability security policy is consistent with the local policy of the grantor organization and the security policy of the grantee organization. Section 1.9 shows how our O2O model applies to manage security of a Virtual Private Organization (VPO). Some privacy requirements and enforcement are discussed in section 1.11. We present a peer-to-peer example to illustrate our approach in section section 1.12. Section 1.13 concludes this chapter.

Usual Approaches for Interoperability

Actually, there exist three ways to deal with interoperability. The first approach is Federation of Identity Management (FIM). The second kind of interoperability related works is security policy oriented and the third way to manage secure interoperability makes use of ontological approaches.

Federated Identity Management

The most famous FIM technologies are Liberty Alliance [START_REF] Cantor | Liberty ID-FF Architecture Overview[END_REF] and Microsoft Passport (Live Identity). [START_REF] Oppliger | Microsoft .net passport: A security analysis[END_REF] FIM generally covers at the same time user management and access management. Several identity services like Single Sign-On, [START_REF] Pashalidis | A Taxonomy of Single Sign-On Systems[END_REF] access control and federation of identities, bring together the necessary components to provide a specific pertaining service to a given identity. However, FIM bases trust relationships on reliability of the identities of each participant. This identity is a set of information known about the participants which could be stored across multiple management systems. Certification of identities relies on a relevant trusted authority. So, FIM could have problems to set up the trust relationships. Furthermore, in most of FIM systems, negotiation exchanges are centralized and participants have to be identified by FIM. This choice limits the use cases of interoperability as FIM relies only on the user identities when dealing with security. Consequently, one of the major problems of FIM is the lack of granularity when assigning privileges. For example, if two organizations B and C belong to a same alliance A, all users of B have the same privileges when they access to C. Our approach provides finer grained access control than one can do with FIM.

Negotiation policy

Because most of access control models often propose a preestablished policy and cannot take into account new requesters, trust negotiation is a good solution for dynamic policies. In this case, the decision to grant an access is primarily based on exchanges of credentials and accesses to the information they convey. Automated Trust Negotiation, [START_REF] Li | Automated trust negotiation using cryptographic credentials[END_REF] TrustBuilder, [START_REF] Toolkit | Trustbuilder download[END_REF] and Trust-χ [START_REF] Bertino | Trust-X: A Peer-to-Peer Framework for Trust Establishment[END_REF] are examples of these approaches. In this case, specific languages have to be defined.

ATN

Automated Trust Negotiation (ATN) is an approach to regulate the exchange of sensitive credentials by using access control policies. The languages used in this case do not make clear separation between the security policy specification and credentials that are used to implement this policy. They are largely inspired by RBAC (Role based Access control) model philosophy. [START_REF] Sandhu | Role-Based Access Control Models[END_REF] The RBAC model does not take into account the organization dimension, which is essential in the case of interoperability to ensure the confinement principle. Moreover, as the concept of role is prevalent in this model, this is not sufficient to express fine grained access control. Our proposal is context-aware and goes beyond the role based C. Coma, N. Cuppens-Boulahia and F. Cuppens approaches.

TrustBuilder

TrustBuilder is is one of the most significant proposed system for negotiation of trust in dynamic coalitions. TrustBuilder rests on ABAC model (attribute-based access control model). [START_REF] Yuan | Attributed based access control (ABAC) for Web services[END_REF] That is, resources access control policies are written as a declarative specification of the attributes needed in order to gain access to these resources. Each participant of negotiation declares his disclosure sequences. These disclosures sequences allow Trustbuilder to construct disclosure tree via the Trustbuilder strategies (Simple Strategy, Relevant Strategy, ...). With these disclosure trees, participants can disclose credentials in order to establish trust and to gain access to a resource. Each node of these trees are labeled with a credential. So, when a participant wants to access to a resource, he just has to disclose gradually requested credential with respect to the resource sensitivity. So this approach incorporates policy disclosure; only policies that are relevant to the current negotiation may be disclosed by the concerned parties. These policies specify what combinations of credentials one can present in order to gain access to a protected resource of the accessed service. In this way, it is possible to focus the negotiation and base disclosures on need-to-know. Since these policies may contain sensitive information, their disclosure can also be managed by a strategy. Furthermore, TrustBuilder project develops a prototype [START_REF] Toolkit | Trustbuilder download[END_REF] whose goal is to create scalable, reusable trust negotiation components. But again, the security policy are not explicitly stated, the focus is mainly on the negotiation aspects.

Trust-χ

Bertino et al. propose Trust-χ an XML-based framework for trust negotiations. [START_REF] Bertino | Trust-X: A Peer-to-Peer Framework for Trust Establishment[END_REF] The architecture of the main component of the trust-X is symmetric and both parties are Servent (Server-Client). So it could be used by peer-to-peer systems. Trust-χ certificates are either credentials or declarations. A credential states personal characteristics of its owner, certified by a Credential Authority (CA), whereas declarations collect personal information about its owner that do not need to be certified. These declarations only help in better customized service. To specify certificates and policies trust-χ use χ-TNL. [START_REF] Bertino | X-TNL: An XML-based Language for Trust Negotiations[END_REF] A novel aspect of χ-TNL presented in this paper is the use of trust tickets and policy preconditions.

All participants in Trust-χ are considered equally. So each party has its system of negotiation and a view on the state of the negotiation process. All information about the user are collected in χ-profiles. So χ-profile contains all users' credential and declarations. All theses documents are XML-structured for a better homogeneity. Information could be constructed by entities which do not share a common ontology, but system could correctly interpret information with the use of namespaces combined with certificate type system.

To reduce the number of exchange in negotiation, Bertino et al. introduce the trust ticket. The trust ticket is produced at the end of well-pass negotiation, and proves that the provider can trust the requester for a given resource. The core of trust ticket is the sequence of certificates which allows the negotiation to be well-pass.

Trust-χ resource can be either a certificate or a service. A resource can be characterized by a set of attributes. Policies for a resource could be defined as follows: p1 = ({}, peer node ← peer id()); p2 = ({p1}, peer node ← DELIV ); One problem of this type of specification policy, is the loops created which make the specification incorrect. So, the system has to check if the chain of policies is well-formed.

In Trust-χ, the trust negotiation is composed of three phases, the first is the introduction phase, the second phase is the sequence generation phase and the third is caching of trust sequence. The second phase can be done by performing the policy evaluation phase (with negotiation tree building), by exchanging trust tickets and by using the sequence prediction module (based on similarity with previous negotiations).

So, Bertino et al. with the use of precondition policies make the administration not user friendly. Because, the policy designer has to be sure that the policy is well-formed. This leads to a real scalability problem in particular in peer-to-peer systems.

Ontological approaches

In the case of interoperability, each organization should inform the other organizations about some knowledge it wants to share with them, in order to help the set up or the continuation of the (potential) interoperability sessions. The requirement is that this knowledge must be understandable by the interoperability session's participants. An ontology provides an explicit conceptualization that describes the semantics of the data and provides a common sharing knowledge which can be easily communicated. Languages such as OWL [START_REF] Mcguinness | Owl web ontology language overview[END_REF] or DAML [START_REF] Connolly | Daml+oil reference description[END_REF] have been developed to share a knowledge model by using ontologies. REI [START_REF] Masuoka | Policy-based Access Control for Task Computing Using Rei[END_REF] and KAoS [START_REF] Uszok | Kaos policy management for semantic web services[END_REF] are examples of models belonging to this category.

KAoS

KAoS is designed to specify and reason on security policies of interoperable environments, such as Grid or Web services. It was firstly based on DAML+OIL [START_REF] Connolly | Daml+oil reference description[END_REF] a language that combines the features of both the DARPA Agent Markup Language DAML and Ontology Interchange Language OIL. Then KAoS language has been extended using the Web Ontology Language OWL. [START_REF] Mcguinness | Owl web ontology language overview[END_REF] KAoS manages positive and negative authorizations and obligations. To facilitate expression of ontologies, KAoS proposes as ontology entries more than one hundred reusable classes of Policy Ontologies. Theses classes are composed of actions, actors, groups, places, policies, etc. Here is an excerpt of a KAoS policy: <rdfs:comment xml:lang="en"> An action </rdfs:comment> <owl:Class rdf:ID="ActionExample"> <rdfs:subClassOf rdf:resource="#CommunicationAction" /> <owl:Restriction> <owl:onProperty rdf:resource="#performedBy" /> <owl:toClass rdf:resource="#MembersOfDomainA" /> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hasDestination" /> <owl:toClass rdf:resource="#notMembersOfDomainA " /> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <rdfs:comment xml:lang="en"> An authorization</rdfs:comment> <policy:PosAuthorizationPolicy rdf:ID="Example"> <policy:controls rdf:resource="#ActionExample" /> <policy:hasSiteOfEnforcement rdf:resource="#ActorSite" /> <policy:hasPriority>10</policy:hasPriority>

In KAoS, policies are administrated using a tool called KPAT (KAoS Policy Administration Tool) which is used also to deal with conflicts appearing in a KAoS security policy. In this case, KPAT calls a conflict Java Theorem Prover (JTP). Therefore, KAoS users can cumulate different classes of policy ontology and then apply JTP to manage the conflicts. Unfortunately, KAoS is restricted to the specification of security policies that do not require the use of variable parameters. It is not a fully context-aware language though some security policies may need to define security rules according to some imposed constraints. These constraints can, for example, depend on parameters that are known at the time of service deployment or execution. Thus, policies expressed with KAoS are not enough dynamic to fit all the interoperability requirements.

REI

REI extends the KAoS language by adding logical variables to increase its expressivity. Like KAoS, REI also manages inconsistency of the security rules. It includes the specification of meta-policies to solve conflicts.

Security policies expressed with REI are based on OWL-lite. [START_REF] Mcguinness | Owl web ontology language overview[END_REF] OWL-lite is an ontological language which allows REI to express security policies with constraints and obligations on environmental resources. But the use of OWL-lite occasions several restrictions in the REI policies expression. For instance, the use of disjunction and negation are not possible and cardinality is reduced to 0 or 1. Therefore, REI extends OWL-lite language by adding variables. This extension allows REI to be more flexible. Three sets compose REI core policies. The first policy set is composed of action combinations and conditions. In that case, predicates are structured as policy objects PolicyOb ject(Action,Condition). These policy objects are permission, prohibition, obligation and dispensation. As prohibitions are negative permissions and dispensations are negative obligations, conflicts can appear in REI security policy specification. These conflicts are solved in metapolicies using override principles (negative over positive preference or vice versa). The second policy set is used to link an entity to a policyOb ject. These entities are agent or object. For instance, the fact that a subject which is a professor has the permission to examine a student is expressed by has(Var, right(examineStudent, pro f essor(Var)). The third policy set expresses actions, their effects and requisite preconditions. However, REI ontology only deals with constraints and description of local entities which is far from being enough in case of interoperability.

Thus, we should go further in this direction to take into account local, external and contextual information and derive a dynamic security policy on which we can reason. That is our proposal in this chapter. The goal of our approach is to anticipate the management of security of potential interoperability sessions. To achieve this goal, we need an approach which allows both fine-grained access control and interoperation. The OrBAC model [START_REF] El Kalam | Organization Based Access Control[END_REF] is an access control model in which the policy designer can express the security policy of an information system at the organizational level, that means independently of the future implementation of this policy. So, the operational system security requirements could be expressed and then deployed over various security components, considered in OrBAC as sub-organizations of the information system organization. This deployment rests also on administrative responsibilities which could be granted to subjects assigned to different roles.

In OrBAC, the traditional access control triple (subject, action, object) is abstracted at the organizational level into the triple (role, activity, view). A role (respectively an activity and a view) is a set of subjects (respectively actions and objects) to which the same security rules apply. This reduces the number of security rules to define. Furthermore, we need to specify dynamic security rules to adapt the policy to the context and satisfy interoperability requirements. OrBAC is context sensitive, so that the policy could be expressed dynamically by taking into account environmental events and states. For instance, the following OrBAC security rule: securityRule( network, permission( peer, access, resource, memberO f network)) means that in organization network, a peer has the permission to access to a resource in a context where this peer is member of network.

Moreover, using the OrBAC model we can specify a decentralized security policy administration that complies with four principles: (1) Organization centric administration, (2) Administration policy definition at the organizational level, (3) Contextual delegation capabilities and (4) Inheritance of security rules through hierarchies. An ontological specification of OrBAC using OWL-DL [START_REF] Mcguinness | Owl web ontology language overview[END_REF] which rests on the four aforementioned administration principles, has been defined to meet interoperability objectives. [START_REF] Coma | Context Ontology for Secure Interoperability[END_REF] In order to avoid overloading the figure 1.1, we have just represented classes and their hierarchies. In the OrBAC model, concrete security policy rules are derived automatically C. Coma, N. Cuppens-Boulahia and F. Cuppens from abstract ones. Using OWL-DL, this derivation is expressed as the following: is permitted(?sub ject, ?action, ?ob ject) ← securityRule(?org, permission(?role, ?activity, ?view, ?context)) ∧ hasProperty(?org, empower(?sub ject, ?role)) ∧ hasProperty(?org, consider(?action, ?activity)) ∧ hasProperty(?org, use(?ob ject, ?view)) ∧ hold(?org, context(?sub ject, ?action, ?ob ject, ?context)).

Derivation in the OrBAC model is computable in polynomial time. [START_REF] Cuppens | High level conflict management strategies in advanced access control models[END_REF] 1.3.2. Interoperability Framework: O2O principles O2O (Organization to Organization) 1 is both a model and a framework to manage interoperability between components having their own policies defined by different organizations.

To explain the basic principles of O2O, let us consider a given organization Alice.org that wants to interoperate with another organization Bob.org. In this case, each organization has to define a Virtual Private Organization (VPO) respectively called Alice2Bob (A2B for short) and Bob2Alice (B2A for short). The VPO A2B is associated with a security policy that manages how subjects from the grantee organization Alice.org, Ograntee, may have an access to the grantor organization Bob.org, Ograntor. We say that the VPO A2B manages the interoperability security policy from Alice.org to Bob.org. The VPO B2A is similarly defined to control accesses of subjects from Bob.org to Alice.org. Hence, a VPO is a dynamic organization created to achieve a given interoperability purpose and canceled once this purpose in no more needed. In a VPO, the Ograntor organization controls interoperability policy and so, the assignment of concrete entity (subjects, actions and objects) to abstract entities (roles, activities and views). Unlike usual virtual organization, in O2O objects are always controlled by their organization. When assigning subjects, actions and objects to their respective roles, activities and views defined in a VPO, some restrictions apply:

• objects come from the Ograntor organization. This is because, in a VPO, the Ograntor organization can only grant access to its "own" objects. • subjects are from Ograntee organization. This is because a VPO is designed to control how subjects from the Ograntee organization may have an access to the Ograntor organization. • actions are from Ograntor organization or could be initiated by Ograntee organization, they are still defined by Ograntor. This is because a VPO must control the action realized on its objects. When this action comes from the Ograntee organization, Ograntor should trust it to execute it.

O2O is formally defined as an extension of the OrBAC model. Organizations which use O2O to interoperate could have different trust levels. For instance, we can have in one hand a military organization which requires a very strict interoperability policy and in a second hand, a store which needs a more attractive policy. Each of these organizations can define interoperability policy with its own security level and access conditions.

Interoperability Establishment Steps: the O2O process

The interoperability process we propose is composed of three steps. (1) The contract definition step, (2) the interoperability security policy definition step and (3) the interoperability security policy management step. The figure 1.3 shows the sequencing of interoperability security policy establishment.

First of all, before the interoperation sessions, the Ograntor organization defines contracts for each organization type it has to interoperate with (cf. section 1.5). For that purpose, the Ograntor defines the scope of each contract. It specifies entities and information that can be provided during interoperability. In the second step (cf. section 1.6), the Ograntor organization defines some patterns of interoperability security rules on the basis of its local security policy and according to the type of interoperability. Thirdly, using ontologies, we establish compatibility relations (cf. section 1.7). Next, using these compatibility relations and contracts, we derive the interoperability security rules (cf. section 1.8). At this stage, the VPO and its interoperability policy is created.

Finally, the Ograntor decides how this VPO will be managed: Centralized, decen-C. tralized or hybrid administration (cf. section 1.9). The Ograntor should also ensure the administration of its interoperability policy. To reach this goal, the Ograntor must express administration rules (cf. section 1.10).

Interoperability Contract

The contract Interoperability security policies defined and managed in VPOs must be compliant with local security policies. They have not to be defined either on the fly or from scratch. Thus, the VPO security policies are derived from the local policies. The Ograntor, based jointly on its objectives (security), its environment (interoperability) and also its cognitive capacities (its own knowledge and knowledge it has about the grantee organization) proposes interoperability contracts. According to the grantee organization type, a contract specifies the way the local policy may be tuned and fixes the scope of this adaptation.

The scope

In the interoperability contract, entities that can be shared are specified. This specification is done using the classes (or sub-classes) to whom these entities belongs. The benefit of using classes is threefold: (1) we avoid to overload all the entities, (2) it does not matter if the entity is a subject, an object or an action as the class overrides this difference and, (3) finally, a class is not organization dependent.

Each class is associated with some attributes. In the logical formalism of the OrBAC model, an attribute is specified by a binary predicate. For example, the fact peername(p1, p1name) means that p1 has an attribute peername whose value is p1name. The predicate classAssign is used to express that some object belongs to some class. For example, classAssign(p1, peerDesc) means that p1 belongs to the class peerDesc. Then, the grantor organization specifies the possible interoperation entities in some given contract using the predicate can be mapped. The fact can be mapped(?grantee, ?Ograntor, ?className) means that all entities belonging to the class ?className can be used, and so mapped during the interoperation between ?Ograntor and ?grantee. Notice that, in that case, ?Ograntor is some organization A and ?grantee can be an organization B or also an organization type, for instance every organization that belongs to some peer to peer network. The effective mapping Among attributes of a class, there are decisive attributes. These decisive attributes indicate which attributes must be used in the ontological mapping process between the grantee and the grantor organizations; other attributes are not taken into account. So, for each class appearing in the interoperability contract, its decisive attributes are specified. This is achieved using the predicate class(?className, ?attribute, Key att). For instance, if the interoperability contract requires that, in order to authenticate a user in some peer to peer network, only one of its identities (IP address, Id client, etc.) have to be mapped, the attributes related to the peer identity are decisive attributes. Moreover, in this example a threshold is specified (only one attribute is needed) and required to conclude that the mapping is accepted.

We can go further. The key attribute requirement can be strengthened. The interoperability contract could specify that, for a mapping to be effective, a particular key attribute (key key attribute) have to be mapped between entities within ontological key attributes. a For instance, in a peer to peer network, only the hash is used to establish a compatibility between the shared files' contents. So, the hash attribute is such a key key attribute. The figure 1. 4 gives examples of such attributes. In figure 1.4, the ontological decisive attributes are underlined. To establish compatibility between two elements, either all the ontological key attributes should match, or more than AmatchT hreshold ratio decisive attributes should match. a To have a mapping between two entities, it is necessary that all their ontological key attributes match (the conjunction of their attributes matches); whereas it is only when some sets of decisive attributes (some disjunction) match that a mapping between two entities is validated (cf. §1.7.1).

Interoperability Contract Specification

In the O2O approach, each organization defines and manages its VPO policies. The administration of VPO must be both compliant with the local security policy and allows the grantor organization to carry out a flexible interoperability. In the following, we set forth VPO policy derivation requirements.

Underivability and Exception

Obviously, some privileges are strictly local to the grantor organization. So, to bound the propagation of the security rules related to these kinds of privileges, the predicate underivable is used. Thus, the following fact:

underivable(?grantee, securityRule(?Ograntor, permission(?r, ?activity, ?view, ?cxt)))

specifies that the securityRule defined in the local policy of ?Ograntor cannot be derivable in the VPO policy of the ?grantee organization or organization type. Moreover, a collaborative organization can have specific security rules related to its security policy externalization. These rules are not used in the local policy. The predicate exception is used to express such exception rules. The fact: exception(?grantee, securityRule(?Ograntor, prohibition(?r, ?activity, ?view, ?cxt))) means that a prohibition is added to the VPO policy when a ?grantee organization requires an interoperability session with ?Ograntor. An exception security rule is either a prohibition or an obligation.

Usually, a conflict can appear between a permission and a prohibition. Thus, exceptions can also create new conflicts. To ease the policy designer's work, we anticipate the resolution of conflicts generated by such exception rules. For this purpose and as suggested in, [START_REF] Cuppens | High level conflict management strategies in advanced access control models[END_REF] conflicts are solved by assigning priorities to security rules. Thus, exception rules are always associated with higher priority than other security rules (including the non derivable rules). This conflict resolution strategy is chosen to manage the shadowing anomaly b and [START_REF] Cuppens | High level conflict management strategies in advanced access control models[END_REF] shows that this strategy is computable in polynomial time.

Compatibility Relation Patterns

A compatibility relation can be defined if and only if an ontological mapping between

Ograntee entities and Ograntor entities has been established elsewhere a new package of security rules is defined and added to the VPO policy. Security rules of the VPO are derived according to this mapping, the contract, underivability and exception requirements and the restrictions to be applied to the local roles specified by the Ograntor organization for a given Ograntee organization (see figure 1.5). We model these restrictions as compatibility relations.

b A rule is shadowed by a higher priority rule if it can never be activated.

Contract

Underivable security rule

Usual security rule

Exception

Local Policy LP VPO

Compatibility

Nuance by Ograntee policy with some interoperability type Let rOgrantor be a role defined in the Ograntor organization and rOgrantee the corresponding grantee role defined in the Ograntee organization. And let O vpo be the VPO associated with Ograntee. There are four main compatibility patterns:

• Total compatibility relation (T compatibility).

If Ograntor and Ograntee are T compatible then, in O vpo , the grantee role rOgrantee inherits all the security rules assigned to rOgrantor along with exception rules. Notice that underivable security rules are not inherited.

• Partial compatibility relation (P compatibility).

If Ograntor and Ograntee are P compatible then, in O vpo , the grantee role rOgrantee inherits the security rules associated with rOgrantor along with some constraints and exceptions. These constraints are restrictions on activities, views, contexts. Underivable security rules are not inherited.

• Symmetric compatibility relation (S compatibility).

If Ograntor and Ograntee are S compatible then, in O vpo , the grantee role rOgrantee inherits the security rules of a common derivable subset of the two local policies of Ograntee and Ograntor, with some constraints, along with some exceptions.

• No compatibility relation (No compatibility).

If Ograntor and Ograntee are No compatible then, in O vpo , there is no security rule related to rOgrantee. In this case, the interoperation cannot take place through the role rOgrantee.

In the case of partial compatibility relation, restrictions on view, activity and context are specified. To do so, we define a restriction predicate for each of these OrBAC entities. For instance, restrictionActivity(Ograntor, A, RA) means that during partial compatibility interoperation the activity A is replaced by the restriction activity RA. For instance, creating activity during interoperability, can be restricted to updating activity. Notice that restriction entity should be included in previous entities.

In our approach, the type of compatibility between organizations having to undertake interoperability sessions must be known. We define the predicate type compatibility for this purpose. The fact, C. Coma, N. Cuppens-Boulahia and F. Cuppens type compatibility(Ograntor, Ograntee, Type),

where Type ∈ {T compatible, P compatible, S compatible, No compatible}, means that Ograntor and Ograntee have a Type compatibility relation.

No compatibility is the default compatible type. When this default type is used this means the end of the collaboration. In this case, all privileges related to this collaboration, if any, are revoked.

First part of contract

In this part, the Ograntor organization indicates which entities are usable during interoperability. By default, all entities are not usable. For instance, in figure 1.6, the action read is not usable (in grey), because any usable class (can be mapped) contains this action. can be mapped(toP2PNetwork, net part1, avi). can be mapped(toP2PNetwork, net part1, mp3). can be mapped(toP2PNetwork, net part1, p2pUser). can be mapped(toP2PNetwork, net part1, p2pAction).

In figure 1.6, we can see that there is a restriction on view f iles. restrictionView(net part1, f iles, sharingMovies).

Second part of contract

In this second part, the Ograntor organization limits the security rules which can be derived to create the interoperation policy. By default, all security rules can be derived such as Licence1.

Licence1: securityRule(net part1, permission(peer, access, f iles, de f ault)).

Some licence , such as Licence2 are not derivable.

Licence2: underivable(toP2PNetwork, securityRule(net part1, permission(player, access, music, de f ault))).

The Ograntor organization also expresses exception.

Licence3: exception(toP2PNetwork, securityRule(net part1, prohibition(peer, access, music, de f ault))).

The Ograntor indicates which compatibility will be used to create interoperability policy.

type compatibility(net part1, toP2PNetwork, P compatible).

Secure Interoperability Policy Establishment

Ontological Mapping

During interoperability, access control cannot be set up without semantic compatibility establishment between security policies of parties that have to interoperate. Entities involved in a collaboration need common knowledge which should be understandable by all parties. We stress on the fact that to get good interoperability, organizations need to share understandable information. To facilitate this sharing, our approach is based on the definition of ontologies and mappings between these ontologies. These mappings allow organizations to provide a shared and common understanding of an application domain that can be exchanged between organizations and application systems undertaking collaboration.

An ontology is composed of instances, ontological classes and properties. Instances represent entities related to ontology domain, and consequently to information system. Ontological classes are sets of instances, used to structure the ontology by the way of relations like hierarchy, intersection, union,... Properties are relationships between instances. Our ontological mapping is based on T BOX mapping related to the mapping of ontological classes, properties between classes and hierarchies, A BOX mapping related to the mappings of instances and R BOX mapping related to the mappings of rules and properties between instances. These mappings apply only to entities that are authorized to be mapped during interoperability by the corresponding contracts. To illustrate the ontological mapping process, we further describe the A BOX mapping, the R BOX mapping and the T BOX mapping.

A BOX mapping: instances mapping A BOX mapping rests on correspondences between attributes and their associated values. Thus, we first have to map attributes before concepts. This kind of mapping has already been studied in several works, such as those done in COMA++ [START_REF] Do | COMA -A System for Flexible Combination of Schema Matching Approaches[END_REF] and GLUE, [START_REF] Doan | Learning to match ontologies on the Semantic Web[END_REF] but without considering security issues. Notice that A BOX mapping is easy to establish or to revoke when the decisive attributes are set up. Thus, to establish A BOX mapping, we compare the number of correspondences of decisive attributes with a threshold, beginning first with ontological key attributes. Let us consider two entities c 1 ∈ Ograntor, c 2 ∈ Ograntee and C. Coma, N. Cuppens-Boulahia and F. Cuppens Sim(c 1 ,c 2 ) the measure of similarity between c 1 and c 2 . First case: c 1 and c 2 have ontological key attributes. In that case, if all the ontological key attributes of c

R BOX mapping: properties mapping

To obtain the R BOX mapping, we analyze class taxonomies of the two organizations that need to interoperate and their inference rules. From internal and composition relations of the security policy ontology, we could derive new information about security policies in one or both of these organizations. For instance, if we consider a common knowledge about the existence of a hierarchical relation between two entities, the views movies and shared movies, this hierarchical relation is automatically derived by the following rule: sub view(?org, ?v1, ?v2) ← view(?org, ?v1) ∧ view(?org, ?v2)∧ restrictionView(?v1, ?v2). Let us assume that both organizations use the same context taxonomy. So, the inference rules associated with the security policy ontology will be the same. In this case, we define a fact viewRmatch(org, pred1(?v1), pred2(?v2)) where pred1 and pred2 are view predicates, ?arg1s and ?args2 their arguments vertex, and viewRmatch means that the two view predicates are compatible. If one of the two view predicates belongs to the other organization undertaking an interoperation, the same fact can be used to establish a compatibility and then derive the security rule to be activated.

T BOX mapping: ontological classes mapping

This is a schema mapping. We could base T BOX matching on existing works. [START_REF] Do | COMA -A System for Flexible Combination of Schema Matching Approaches[END_REF][START_REF] Doan | Learning to match ontologies on the Semantic Web[END_REF][START_REF] Madhavan | Generic Schema Matching with Cupid[END_REF] As T BOX matching requires both schema and semantics correspondences, these works simplify and automatize search of entities matching. An OrBAC security policy is defined independently of its implementation. So, in order to preserve this suitable property in our ontology mapping, we have to define a more generic mapping than the classical mappings between two organizations. The reuse of previously global established mapping results simplifies interoperability.

For instance, during file exchanges in a P2P network, several view mappings are similar. In this case, there are two ways to reuse these pre-established similar mappings: 1) we could define mappings common to all peers of the networks. These common mappings could be managed by a server, or 2) we could determine a mapping between two peers of the network and try to generalize this mapping to other peers. This allows us to define a hierarchy of mappings in the ontology structures.

CUPID [START_REF] Madhavan | Generic Schema Matching with Cupid[END_REF] is a good T BOX mapping approach.

To establish when view T match(?org, ?v1, ?v2) is true, A BOX similarities have to be established first. There are three structuring cases to get a T BOX matching: (1) the compared views or entities have no sub-views, (2) all sub-views of the two mapped views are globally mapped by A BOX mappings, 3) the hierarchy schema of the two views are structurally similar and a set of sub-views are mapped by A BOX mappings, even if immediate sub-views of the two views are not mapped.

Establishment of Compatibility Relations

The establishment of compatibility relations is a prerequisite condition to the derivation process of interoperability security rules. It is based on the three aforementioned ontological mappings, T BOX , A BOX and R BOX and the four compatibility relation patterns: no compatibility, total compatibility, partial compatibility and symmetric compatibility. So, for each entity used to express a security rule in the access control model (namely role, activity, view and context), we define a compatibility predicate. The role compatibility predicate is defined as the following: role compatibility(?orga2orgb, ?ra, ?rb) ← roleT match(?orga2orgb, ?ra, ?rb). which means that, in the VPO orga2orgb, two roles ra and rb are compatible, if there exists an ontological mapping between ra and rb. The view compatibility predicate is defined as the following: view compatibility(?orga2orgb, ?resVa, ?vb) ← viewT match(?orga2orgb, ?va, ?vb) ∧ grantor(?orga2orgb, ?orga) ∧ grantee(?orga2orgb, ?orgb) ∧ restrictionView(?orga, ?va, ?resVa) ∧ type compatibility(?orga, ?orgb, P compatibility).

which means that two views resVa and vb in the VPO orga2orgb are compatible if there exists an ontological mapping between a view va belonging to the grantor organization orga and a view vb belonging to the grantee organization orgb and, resVa is a restricted view of va and, there is a P compatibility relation between orga and orgb.

The two predicates activity compatibility and context compatibility are similarly defined.

Derivation of the Interoperability Security Policy: automatic VPO creation 1.8.1. Derivation rules

Once some agreements exist on the compatibility of entities of those organizations having to undertake some interoperability sessions, security rules are derived from the local policies. C. Coma, N. Cuppens-Boulahia and F. Cuppens

Total compatibility

In the case of total compatibility, a security rule is derived as the following: securityRule(?orga2orgb, permission(?rb, ?a, ?v, ?c)) ← type compatibility(?orga, ?orgb, T compatibility) ∧ grantor(?orga2orgb, ?orga) ∧ grantee(?orga2orgb, ?orgb) ∧ securityRule(?orga, permission(?ra, ?a, ?v, ?c)) ∧ role compatibility(?orga2orgb, ?ra, ?rb) ∧ not(underivable(?orgb, securityRule(?orga, permission(?rb, ?a, ?v, ?c))).

Partial compatibility

In the case of partial compatibility type, the security rule derivation depends on restrictions. Notice that if an entity has no restriction, the restriction of this entity is itself: securityRule(?orga2orgb, permission(?rb, ?resA, ?resV, ?resC)) ← type compatibility(?orga, ?orgb, P compatibility) ∧ grantor(?orga2orgb, ?orga) ∧ grantee(?orga2orgb, ?orgb) ∧ securityRule(?orga, permission(?ra, ?a, ?v, ?cxt)) ∧ role compatibility(?orga2orgb, ?ra, ?rb) ∧ restrictionView(?orga, ?v, ?resV ) ∧ restrictionActivity(?orga, ?a, ?resA) ∧ restrictionContext(?orga, ?c, ?resC) ∧ not(underivable(?orgb, securityRule(?orga, permission(?rb, ?a, ?v, ?c))).

Symmetric compatibility

When the contract specifies a symmetric compatibility, the concerned activities, views and contexts in the grantee and grantor organizations have to be compatible: securityRule(?orga2orgb, permission(?r, ?ab, ?vb, ?cb)) ← type compatibility(?orga, ?orgb, S compatibility) ∧ grantor(?orga2orgb, ?orga) ∧ grantee(?orga2orgb, ?orgb) ∧ securityRule(?orgb, permission(?r, ?aa, ?va, ?ca)) ∧ activity compatibility(?orga2orgb, ?aa, ?ab) ∧ view compatibility(?orga2orgb, ?va, ?vb) ∧ context compatibility(?orga2orgb, ?ca, ?cb) ∧ not(underivable(?orgb, securityRule(?orga, permission(?r, ?ab, ?vb, ?cb))).

Example of derivation of an interoperability rule

Let us take an example of derivation of an interoperability rule.

securityRule(network, permission(node, access, sharingMovies, law f ullyMovies)) ← type compatibility(net part1, net part2, P compatibility) ∧ grantor(network, net part1) ∧ grantee(network, net part2) ∧ securityRule(net part1, permission(peer, access, f iles, de f ault)) ∧ role compatibility(network, peer, node) ∧ restrictionView(net part1, f iles, sharingMovies) ∧ restrictionActivity(net part1, access, access) ∧ restrictionContext(net part1, de f ault, law f ullyMovies) ∧ not(underivable(net part2, securityRule(net part1, permission(peer, access, f iles, law f ullyMovies))).

In this example of security rule derivation, organization net part2 has established a partial compatibility type with organization net part2. So, the permission of a peer in the grantee organization net part1 to get an access to a file belonging to the grantor organization net part2 must be tuned in the VPO network during the interoperability sessions. The default context is restricted to a context related to law f ullyMovies. The role peer must be compatible with the role node. Furthermore, organization net part1 restricts its file to an interoperable view SharingMovies. So, in the interoperability security policy we derive the permission for a node in the VPO organization network to access to interoperation files in the law f ullyMovies context, that is to say movies which respect the legal age according to the grantee country.

VPO management: Secure interoperation policy management

In a Virtual Organization (VO), several organizations share some of their subjects, actions and objects to achieve a common purpose. Usually, an initiator organization, which wants to create a VO, will have to issue a query to other organizations it wants to interoperate with. The VO will be created if all the organizations that receive this query agree to be a member of this VO. Each of these organizations will require that the access to its resources must be compliant with some security policy. We claim that these interoperability security policies defined by the different organizations actually correspond to VPOs.

Thus, in our O2O approach, the security policy of the VO is the union of all these VPOs. The problem is then to define how to manage the security policy of the VO. There are three main approaches: decentralized VPO management, centralized VPO management and hybrid VPO management.

Decentralized VPO management:

Like we have seen before, each organization defines its VPOs to control interoperability with other organizations in the authority sphere. Then, each organization will manage those VPOs that are inside its sphere of authority. The decentralized VPO management corresponds to the figure 1.7. When a subject of a given organization A wants to have an access to another organization B, this subject will issue a query. Organization B will apply the VPO A2B to check whether this query is authorized. This will generally require exchanging credentials between A and B for negotiating the access. If this negotiation phase succeeds, then the access will be granted.

Centralized VPO management:

In the centralized VPO management case, a VPO is both in the authority sphere of a given organization which is in charge of defining its interoperability policies and in the manage- ment sphere of a server (see figure 1.8) which is in charge of managing all the interoperability policies of those organizations that trust this server. So, managing the VPOs is delegated to a unique trust server, which may be viewed as an extension of a CAS server (Globus toolkit) 23 or an advanced PEP, say PMP for Policy Management Point. Once a VO is created, each organization involved in this VO will have to send its VPOs to this server. When a subject s A from a given organization A wants to have an access to another organization B, this subject must send its query to the server. The server will first authenticate this subject to get the proof that this subject is member of one of those organizations involved in the VO. Then the server will apply the VPO A2B and negotiate the access on behalf of organization B. If this negotiation succeeds, the server will sign the query so that the subject can then present this query to organization B for evaluation.

Hybrid VPO management:

The sensitivity of interoperation may vary. In the case of organizations (P2P or Server exchanges for instance) that deal with high sensitive information, assigning the task of managing the interoperability policies to a server may not meet the high confidentiality requirements of such organizations. When some Virtual Organization is created, organizations involved in this VO may not trust the server used in the Centralized VPO Management approach and/or may not accept to send their interoperability policies to this server because this may lead a leakage of some sensitive information and/or some of these organizations may not agree to interoperate with some organizations involved in this VO. In both cases, Hybrid VPO management may be used (see figure 1.9). In this figure, three organizations A.org, B.org and C.org agree to interoperate through Centralized VPO management, whereas the fourth organization D.org only accepts to interoperate with organization A.org using Decentralized VPO management.

In every approach, the interoperability policies are specified using the OrBAC model. The authority or the management sphere checks for each query(s,a,o) if a concrete permission for subject s to do action a on the object o can be derived from the specified VPO policies. The main advantage of the centralized management approach over the decentralized one is that, since the trust server has a global view of all the VPOs, it can manage possible conflicts between these VPOs. tration is also used to define who is permitted to manage entities and their assignment, that is to say who is permitted to create, update or revoke existing entities and their relations with organization. O2O is used to manage interoperation security policies. To secure the management of these interoperation security policies, we should have information on their administration. An information system has a great number of security rules and to satisfy integrity and security requirements, someone should manage the creation, updating and deletion of these rules. That is why information system should be administrated. In general, due to information system sizes, there are several policy designers. these policy designers have several administration privileges.

There are some administration requirements to be satisfied. In particular,

• we have to specify a structure that defines and/or administrates the security policy. In O2O, this structure is the organization Ograntor. • we should have multi-grained privileges to limit the number of security rules and manage exceptions. The view License defined in the administration model of OrBAC can be used to achieve this goal. • Administration should provide means to specify delegation. In usual administration models, delegation is specified using a separated model.

The administration model for OrBAC, AdOrBAC [START_REF] Cuppens | Multi-granular licences to decentralize security administration[END_REF] is defined as an extension of the OrBAC model. AdOrBAC objectives are : (1) no separation between regular and administrative roles, (2) the self-administration, AdOrBAC uses same predicates as OrBAC to administrate OrBAC, (3) a multi-grain administration and (4) the enforcement of confinement principle. The confinement principle which limits the scope of privileges to organization, restricts the authority of a subject to the organization (or sub-organizations) to which this subject has been assigned administration privileges. The administration is achieved using administration views.

There are four types of administration views related to our security policies:

• OEntities: we have to manage organizational and concrete entities used to express security rules (subjects, actions, roles,...). • OEntity Assignement: typically abstract entities have to be assigned to concrete entities (subject/role, action/activity). • Olicence: contextual and fine grained privileges (permission, prohibition, obligation) are assigned using an administrative view called licence. • OEntity Hierarchy: we have to control hierarchy relations, because hierarchies propagate privileges (role hierarchy,...).

When someone obtains a permission to insert an administrative object in one of the above administration views, he obtains the administrative permissions related to this view.

Licence

In our approach, we use administrative access control object called licence (cf. the paper [START_REF] Cuppens | Multi-granular licences to decentralize security administration[END_REF] ).

To specify administrative security policies, some subjects will be permitted to create, update or delete particular objects. These objects (licences) have a specific structure and meaning, namely the existence of a valid licence will be interpreted as the assignment of some permission. The notion of licence facilitates exportation of our security rule during exchanges. The license class, related to administration objects of Olicence view, is used to specify and manage the security policy. This class is associated with the three following attributes: (1) authority: organization in which the licence applies, (2) grantee: subject or role to which the licence is granted, (3) privilege: action or activity permitted by the licence, (4) target: object or view to which the licence grants an access and (5) context: specific conditions that must be satisfied to use the licence. Figure 1.11 shows the derivation rule related to a licence.

Privacy

During interoperability organizations should provide information on their security policies and some of these information are private and should not be known by non authorized external entities. So, we must provide a solution to protect the privacy of the organization when it enters an interoperability session. As our interoperability security policies are expressed using ontological languages and XML files, [START_REF] Bray | Extensible Markup Language (XML)[END_REF] we can deal with the privacy aspect through an obfuscation process of these security policies based on XML-BB principles [START_REF] Cuppens | Protection of Relationships in XML Documents with the XML-BB Model[END_REF] .

XML-BB

XML-BB model introduces the concept of blocks and provides means to protect relationships in the XML documents. XML-BB rest on two principles to build the authorized view associated with an XML document.

Let us consider that the security policy is an XML document represented by a tree and some nodes in this tree are connected by edges, two principles are used to build the authorized view associated with an XML document:

• Cumulative principle: The effect of two GRANT (i.e. permission) rules is cumulative, that is the resulting permissions actually correspond to the union of the nodes respectively selected by theses rules. • Connectivity principle: If two selected nodes are connected by an edge in the XML document, then this edge will appear in the view presented to the user.

It is the combination of these two principles that sometimes fails to protect some information we need to hide. XML-BB is based on the new notion of block that avoids this problem. Intuitively, relationships between nodes selected in the same block are preserved whereas relationships between nodes selected in two different blocks are broken. Thus, an access control policy is specified using several blocks. In some sense, this is similar to the Chinese Wall security model suggested by Brewer-Nash. [START_REF] David | The Chinese Wall security policy[END_REF] In a Chinese Wall policy, a user may be permitted to have an access to different entities, but due to some conflict of interest between theses entities, this user is not permitted to aggregate this information. When we use two different blocks to specify an access control policy, we can in some sense consider that there is a wall between these two blocks. XML-BB allows us to express both a GRANT or REVOKE read access privilege and write privileges (insert, update and delete) on an XML file.

In the case of obfuscation, we use the same procedure to limit the access to security policy. There are three options to perform this obfuscation:

• Propagate: This option will select every sub-node of a selected node.

• Shuffle: This option will randomly shuffle the selected nodes. If a shuffled node is the root of a sub-tree, then this node will be the root of the same sub-tree after the shuffling operation. • Masquerade: This option will replace the value of a selected node by the new value specified in the option. This is used to hide the value of a given node without hiding the existence of this node.

Obfuscation

With XML-BB, we consider that an access control policy is defined as a set of blocks. As we have seen in §1.7.1, an ontology is composed of instances, ontological classes and properties. So, we have two types of blocks in an ontology: instance block and ontological class block. Due to the existence of these two kinds of blocks, according to XML-BB block concept, we have two ways to obfuscate security policies: the generic obfuscation and the specific obfuscation.

Generic obfuscation

This method is related to ontological class blocks. When we specify the type of access on a class block, we shall prohibit or permit access under some conditions to a whole set of instances. For example, our XML-BB approach may obfuscate any set of entities considered as internal objects and noncommunicable. Let us consider that during an interoperability session, we do not want to communicate information on concrete entities that cannot be used for this session. From the Ograntor point of view, all information related to object and action classes should be hidden. In this case, we will specify that we revoke privileges on object class block to an external subject using the fact: REVOKE read, write /P ON = ob ject T O externalSub ject. The /P means that the revocation is propagated to all the sub-nodes.

The advantage of generic obfuscation is that as a class is represented by a block with a unique path, we only have to find in the XML file the node related to this class. A simple XML file search algorithm based on depth-first search can be used to find the chosen node. Furthermore, we can distinguish ontological class block from the other blocks, as they begin by the tag rdfs:Class and finish by /rdfs:Class. Once, the block related to ontological class is founded, we have two cases: (1) The class does not have any subclass, in this case, we only have to hide all instances related to this class, that is done by propagation. (2) The class has some subclasses, in this case, we have to decide, if the obfuscation has to be propagated to the subclass or not. In last case, we have to distinguish (based on the tags) sub-blocks related to classes or to instances in the XML file. In that sense, we can define an exception rule to limit the propagation: GRANT read /P ON /ob ject/. W HERE rd f s : subClassO f := ob ject T O externalSub ject. This requirement means that externalSub ject is permitted to read sub-nodes of node ob ject if they are subclasses of the class ob ject. As noticed by the XML-BB's authors, [START_REF] Cuppens | Protection of Relationships in XML Documents with the XML-BB Model[END_REF] XML-BB algorithm applies the last matching principle; when several rules apply to the selected node, the last rule is applied.

Specific obfuscation

This method is related to instance blocks. It consists in hiding all blocks related to some information of a given entity. For instance, we can obfuscate all information on an identity if we hide all attributes related to this identity. We can also hide specific entities using administrative objects. For instance, if we want to get some information on a role R in a security policy, we look for the relation role or for all administrative objects with role attributes such as grantee. So, if we want to revoke privileges related to role Root to external subjects, the following fact meets this security requirement: REVOKE read, write /P ON /parent :: . W HERE grantee = Root T O externalSub ject. Structurally, in the XML file, instance blocks are sub-trees of the ontology. So, to take care about all information related to an instance, we should browse the different sub-trees and find all the sub-blocks related to some specified information. Then, depending on the obfuscation expression, we hide all information related to instance attributes by masquerading (specifying "ON /.:" on the current block, that is to say attribute) or we hide all instances related to some attribute description by propagation (specifying "ON /parent :: .:" on an upper block, that is to say instance).

1.12. Illustration 1.12.1.

P2P and interoperability

As seen in the related works (cf. §1.2), most of the usual approaches rest on a centralized administration of policies to create collaborations, like in CAS server, [START_REF] Pearlman | A community Authorization Service for Group Collaboration[END_REF] or are not sufficient to express fine grained access control. The increasing use of spontaneous networks like peer to peer [START_REF] Sandhu | Peer-to-peer access control architecture using trusted computing technology[END_REF][START_REF] Tran | A Trust based Access Control Framework for P2P File-Sharing Systems[END_REF] tends to require a decentralized administration of the collaboration resources. In that case, the security of this kind of interoperability environments remains a hard problem. As a matter of fact, peer-to-peer systems can be very dynamic and the peers' volatility is a barrier to a negotiation process setting during access control checking. Furthermore, P2P networks have many specific problems. For instance, in P2P systems, a peer is anonymous, so it is difficult to establish trust relationships. File sharing mitigates free-riding problem, but it is a spread vector of corrupted and malicious files. As suggested in this chapter, the O2O framework is based on the concept of contract that each interoperability policy of sub-organization has to comply with. This approach significantly contributes to secure the collaboration. In the following, we illustrate the interoperability policy derivation process using a P2P scenario.

Obfuscation during interoperability

In figure 1.12, we can see the composition of view f iles. The corresponding interoperability contract specifies a restriction on this view: restrictionView(net part1, f iles, sharingMovies). net part1 wants to obfuscate unusable elements on f iles view. To achieve this goal, net part1 defines the bloc FILEStoP2Pnetwork and its access rules. GRANT read /P ON / f ile/sharingFiles/sharingMovies/. T O P2Pnetwork. ENDBLOCKFILEStoP2Pnetwork 1.12.3. P2P and O2O contract Let Robert be a new peer that joins the P2P network peerNetwork. Robert wants to get an access to the Resident Evil movie. So, First, Robert emits a search request to find this movie. The Distributed Hash Table indicates that two peers own the Resident Evil movie: P 1 and P 3 . Then, Robert sends a resource request to P 3 to get an access to Resident Evil. A resource access request is composed of an interrogative license and can also contain the authorization proofs (credentials). The corresponding access request looks like the following: accessRequest(?number, @Robert, resourceAccess, license[authority(L, @Dest), grantee(L, Robert), privilege(L, download), target(L, ResidentEvil), context(L, de f ault)]), @polRobert).

where ?number is the identifier of the request, grantee, privilege, target and context are license information. @polRobert is the URI of Robert's security policy. @Robert is Robert's address. @Dest is the grantor's address, in this case P 3 address. P 3 contract specifies that there is No compatibility type with a peer which has never exchanged resources in peerNetwork. Thus, Robert cannot download Resident Evil from P 3 . This denial of access leads Robert to send a request to another peer P 1 which owns the same resource, the Resident Evil movie. P 1 contract specifies that there is a T compatibility type with a peer pertaining to peerNetwork. So, to establish a VPO security rules between P 1 and Robert, we only have to establish role compatibility. To do so, Robert provides a RDF file of his security policy, which is easily exchangeable because it rests on XML. Robert can hide information which are not related to roles. Then, P 1 derives from its local security policy and this RDF file the VPO Robert2P 1 . The security policy of VPO Robert2P 1 is created in a new RDF file and identified by the URI @Robert2P 1 . Thus, P 1 can send the VPO file to a server; and Robert can consult the VPO at the address @Robert2P 1 . In our example P 1 decides to restrict the access to Resident Evil according to legal condition related to the grantee country. So, the law f ullyMovies context is then defined as the following: hold(Robert2P 1 , law f ullyMovies(?S, download, ?Movie)) ← ip adress(?S, ?ipAd) ∧ country(?ipAdr, ?Country) ∧ declared age(?S, ?AgeS) ∧ lawMovie(?Age, ?Country, ?Movie) ∧ in f erior(?Age, ?AgeS).

In France, children less than 12 years old are prohibited from watching Resident Evil movie. Thus, the management sphere, who is in charge of managing the VPO Robert2P 1 , requires Robert to prove his age (for instance, via a credential). If this phase succeeds, then Robert can download Resident Evil from P 1 .

Conclusion

To facilitate collaboration between organizations, conflict between security scopes should be detected and solved. Furthermore, interoperability requires reactivity, flexibility and continuity of service. In this chapter, we suggest a new approach to facilitate secure interoperation between organizations and preserving privacy property. This approach is defined as an extension of the O2O approach. In O2O, each organization administrates its resources so that it is always possible to know which security policy is applied to the resource. The objective of the suggested extension is to automatically derive interoperability security rules. This derivation depends on the following taxonomy of interoperability relations: total compatibility relation, partial compatibility relation, symmetric compatibility relation and no compatibility relation. These compatibilities can be refined with exception rules.

The main innovation of our approach is to provide a solution to anticipate over security requirements before the interoperability establishment. This anticipation is possible due to the abstraction of the whole security policy and its independency of the implementation. To interoperate securely and anticipate on this interoperation, we use the notion of contract. A contract which is defined by the grantor organization, specifies for each grantee organization, which grantor's resources or part of these resources are accessible. Moreover, as the interoperability security policies are derived from the grantor security policy, according to the nature of the contract, adaptation constraints of this security policy may be also specified. In this way, the grantor organization controls the accesses to its resources during interoperability sessions without weakening the security policies of the grantee organizations. An automatic derivation process of the interoperability policies based on these contracts has been defined. Since our approach to manage interoperability is defined as an extension of the OrBAC model, derivation of interoperability policies has actually similar complexity as derivation in the OrBAC model, namely polynomial. We are currently implementing this derivation process as an extension of MotOrBAC, 31 a toolkit that supports the specification of security policies using the OrBAC model.

1. 3 .

 3 Generic Interoperation Policies 1.3.1. Contextual Security Policy: the OrBAC model

Fig. 1 . 1 .

 11 Fig. 1.1. OrBAC Ontology.

Fig. 1 . 2 .

 12 Fig. 1.2. O2O (Organization to Organization) Framework.

Fig. 1 . 4 .

 14 Fig. 1.4. Decisive Attributes and Ontological Key Attributes.

Fig. 1 . 5 .

 15 Fig. 1.5. VPO Derived from Contract.

Fig. 1 . 6 .

 16 Fig. 1.6. Example of Contract.

  1 and c 2 match, Sim(c 1 ,c 2 ) = 1, else Sim(c 1 ,c 2 ) = 0. Second case: c 1 and c 2 have no ontological key attributes but decisive attributes. We use a normalized value. So, let |A c 1 | be the number of decisive attributes associated to c 1 and |A c 1 ∩ A c 2 | the number of decisive attributes c 1 and c 2 have in common. Then, the similarity Sim between c 1 and c 2 is evaluated using the formula Sim(c 1 ,c 2 ) = |A c 1 ∩A c 2 | min(|A c 1 |,|A c 2 |) ∈[0..1]. Then, A BOX mappings are established if the similarity value belongs to the interval [AmatchT hreshold, 1]. AmatchT hreshold is a threshold set by the Ograntor organization and specified in the contract.

Fig. 1 . 8 .

 18 Fig. 1.7. Decentralized VPO Management.

1. 10 .Fig. 1 . 9 .

 1019 Fig. 1.9. Hybrid VPO Management.

Fig. 1 .

 1 Fig. 1.11. Licence and Derivation Rule from Licence Attributes.

  BEGINBLOCKFILEStoP2Pnetwork REVOKE read, write /P ON / f ile T O P2Pnetwork. REVOKE read, write /P ON /music T O P2Pnetwork. REVOKE read, write /P ON /persoFiles T O P2Pnetwork.

Fig. 1 .

 1 Fig. 1.12. Composition of net part1 Files.

  Coma, N. Cuppens-Boulahia and F. Cuppens

	Before interoperation		VPO created
	Restriction of usable entities	Can_be_mapped class Key attributes definition	Derivation Interoperation Policy Rules	VPO creation	Secure Interoperation Policies Management	VPO management • Decentralized •Centralized •Hybrid
	contract type Defintion of	Underivable, Compability type exception rules Restriction entities	Establishment Policies Secure Interoperation	establishment Compatibility Ontological mapping • R Box match •TBox match •ABox match	Interoperation
	Ograntor accepts to interoperate with Ograntee
	Fig. 1.3. Sequence of Interoperability Security Policy Establishment.

Secure interoperability with O2O contracts


Abdeldjalil Aissa

El Bey

Karim Abed-Meraim

Christophe Laot

Abdeldjalil Aïssa-El-Bey

Adaptive blind estimation of sparse SIMO channels

Keywords: Adaptive algorithms, stochastic gradient, sparse channel, p norm, robustness

come

INTRODUCTION

Blind channel identification is a fundamental signal processing technology aimed at retrieving the channel information from its outputs only. This problem has received a lot of attention over the last two decades and many efficient solutions exist for SIMO and MIMO systems [?, ?, 1]. Unfortunately, these methods become inefficient (i.e. non robust or with poor estimation performance) when the channel impulse response is very long (i.e. wireless communication, echo cancelation etc), and/or sparse [2]. Such channels are encountered in many applications including underwater acoustic communication [START_REF] Kocic | Sparse equalization for real-time digital underwater acoustic communications[END_REF]. Recently some of the 'standard' blind identification methods have been modified and adapted to the sparse case either by constraining the desired solution through an p norm based cost function with 0 < p ≤ 1 which is considered as a good sparsity measure [START_REF] Aïssa-El-Bey | Blind identification of sparse SIMO channel using maximum a posteriori approach[END_REF][START_REF] Aïssa-El-Bey | Blind SIMO channel identification using sparsity criterion[END_REF] or by using a specular channel parametric model [?, 2]. In this paper, we extend the work in [START_REF] Aïssa-El-Bey | Blind SIMO channel identification using sparsity criterion[END_REF] by considering the adaptive implementation of the CR and SCR and comparing the convergence speed and steady state performance of the proposed algorithms. We start by reviewing the CR and SCR methods, then we propose gradient like adaptive algorithms in a tracking scheme. In order to improve the convergence rate, we introduce an adaptive step size methodology which improves significantly the algorithm's performance at the cost of a slight increase of the computational cost.

DATA MODEL

The problem addressed in this paper is to determine the sparse impulse response of a SIMO system in a blind way, i.e. only the observed system outputs are available and used without assuming knowledge of the specific input signal. Consider a mathematical model where the input and the output are discrete, the system is driven by a single-input sequence s(n) and yields M output sequences x1(n), . . . , xM (n), and the system has finite impulse responses (FIR's) hi(n) = 0, for n = 0, . . . , L and i = 1, . . . , M . Such a system model can be described as follows :

         x1(n) = s(n) * h1(n) + w1(n) x2(n) = s(n) * h2(n) + w2(n) . . . xM (n) = s(n) * hM (n) + wM (n) (1)
where * denotes linear convolution and w(n) = [w1(n), . . . , wM (n)] T is an additive spatial white noise, i.e. E[w(n)w(n) H ] = σ 2 IM where (•) T and (•) H denote the transpose and the conjugate transpose, respectively and IM is a M × M identity matrix. In vector form, equation (1) can be expressed as :

x(n) = L k=0 h(k)s(n -k) + w(n) , (2)
where h(z) = L k=0 h(k)z -k is an unknown causal FIR M × 1 transfer function satisfying h(z) = 0, ∀z. Given a finite set of observation vectors x(1), . . . , x(T ) and based on the channel entries co-primness (i.e. h(z) = 0 ∀z), the objective here is to estimate the channel coefficients vector h = [h(0) T , • • • , h(L) T ] T up to a scalar constant (this is an inherent indeterminacy of the blind system identification problem as shown in [1]).

CR-LIKE METHODS

Cross-Relations method

From equation (1), the noise-free outputs xi(n), 1 ≤ i ≤ M are given by :

xi(n) = s(n) * hi(n), 1 ≤ i ≤ M . (3)
Using the commutativity of convolution, it follows :

hj(n) * xi(n) = hi(n) * xj(n), 1 ≤ i = j ≤ M . (4)
This is a linear equation satisfied by every pairs of channels. It was shown that, based on the M (M -1) 2 possible cross-relations, the channel parameters can be uniquely identified according to [1] :

Theorem 1 Under the data model assumptions, the set of crossrelations (in the noise free case) :

xi(n) * h j (n) -xj(n) * h i (n) = 0, 1 ≤ i = j ≤ M (5)
where h (z) is a M × 1 polynomial vector of degree L, is satisfied iff h (z) = αh(z) for a given scalar constant α.

By collecting all possible pairs of M channels, one can easily establish a set of linear equations. In matrix form, this set of equations can be expressed as :

X M h = 0 , (6)
where X M is defined by :

X 2 = [X2, -X1] (7)
and

X l =      X l-1 0 X l 0 -X1 . . . . . . 0 X l -X l-1     
with l = 3, . . . , M and :

X l =    x l (L) . . . x l (0) . . . . . . x l (T -1) . . . x l (T -L -1)    .
In the presence of noise, equation ( 6) can be naturally solved in the least-squares (LS) sense according to :

h = arg min h 2 =1 h H X H M X M h . (8)
The CR method is referred to as the LS method in [1] because it represents the least-squares solution to the CR equation ( 6).

Sparse Cross-Relations method

In this section, we propose an iterative algorithm for the identification of sparse channels in the SIMO system case, namely the Sparse Cross-Relations method (SCR). The sparsity property can be measured by the p norm where 0 < p ≤ 1. More specifically, one can define the following sparsity based contrast function :

J (h) = X M h 2 2 + λ h p p (9)
where λ > 0 is a weighting parameter which controls the trade-off between approximation error and sparsity. The first term is the crossrelations criterion and the second term is the penalty term which minimizes the p norm of the channel impulse response h. It is well known that the concavity of this p norm function yields the sparse solution [START_REF] Kreutz-Delgado | Sparse basis selection, ICA, and majorization : towards a unified perspective[END_REF]. Therefore, the desired solution of h is determined by minimizing the cost function J (h) under the unit norm constraint h 2 = 1 :

h = arg min h 2 =1 h H X H M X M h + λ h p p . ( 10
)
Direct minimization is computationally intensive and may be even intractable when the channel impulse response is long and when the number of channels is large. Here, a stochastic gradient technique is proposed to solve this minimization problem efficiently :

h k+1 = h k -µ∇J (h k ) (11)
where µ is a small positive step size and ∇ is a gradient operator. The gradient of J (h) is given by :

∇J (h) = ∂J (h) ∂h = 2 X H M X M h + λ h (12)
where

h(i) = p sign (h(i)) |h(i)| p-1 for i = 1, . . . , M (L + 1) . ( 13
)
The unit norm constraint is to ensure that the iterative algorithm do not converge to a trivial solution with all zero elements. However, we observe that the gradient of the p norm (13) may diverge if |h(i)| is close to zero and 0 < p ≤ 1. Therefore, to avoid this problem, we introduce the parameter ε > 0 in order to provide stability and to ensure that a zero-valued component in h k does not strictly prohibit a nonzero estimate at the next step

h ε (i) = p sign (h(i)) (|h(i)|+ε) p-1 for i = 1, . . . , M (L+1) , (14)
Therefore, the update equation is given by :

h k+1 = h k -µ 2 X H M X M h k + λ h ε k h k -µ 2 X H M X M h k + λ h ε k 2 .

ADAPTIVE IMPLEMENTATION

For blind channel identification to be practically useful in realtime applications, it is imperative that the algorithm should be computationally simple and can be adaptively implemented. In this section, we present an adaptive implementation of the CR and penalized CR algorithms with least mean square (LMS) and normalized least mean square (NLMS) approache.

Adaptive CR implementation

In the same way that in the block approach, the cross-relations between the sensor outputs can be exploited to estimate the channel impulse responses. In this case, we can rewrite the CR criterion as follows :

J (h) = h H Q M (n)h , (15)
where

Q M (n) = γ Q M (n -1) + X H M (n)X M (n) ,
with X M (n) given computed by using equations ( 7), (3.1) and

X 2(n) = [x2(n), -x1(n)] (16)
and

X l (n) =      X l-1 (n) 0 x l (n) 0 -x1(n) . . . . . . 0 x l (n) -x l-1 (n)      (17)
with l = 3, . . . , M and :

x l (n) = x l (n) . . . x l (n -L) . (18)
Therefore, the desired solution for h is determined by minimizing the mean value of the cost function J (h) :

h = arg min h 2 =1 E h H Q M (n)h
Here, an LMS algorithm is proposed to solve this minimization problem efficiently. Then, the filter coefficient vector is then update by :

hn+1 = hn -2 µ Q M (n) hn hn -2 µ Q M (n) hn 2 .
However, the LMS algorithm suffers from slow and data-dependent convergence behavior. The normalized LMS (NLMS) [START_REF] Haykin | Adaptive filter theory[END_REF], an equally simple, but more robust variant of the LMS algorithm, exhibits a better balance between simplicity and performance than the LMS algorithm. Therefore, we present in what follow, a NLMS approach to optimize the CR criterion. One easy way to find adaptive algorithms that adjust the new channel vector hn+1 from the old one hn is to minimize the following function [START_REF] Haykin | Adaptive filter theory[END_REF] :

L [hn+1] = d [hn+1, hn] + µ h H n+1 Q M (n)hn+1
where d [hn+1, hn] is a measure of distance from the old to the new channel vector and η is a positive constant. The magnitude of represents the importance of correctiveness compared to the importance of conservativeness [START_REF] Kocic | Sparse equalization for real-time digital underwater acoustic communications[END_REF]. To minimize L [hn+1], we need to set its derivative

∂L[h n+1] ∂h n+1
to zero. Hence, the solution will be found by solving the equation :

d [hn+1, hn] ∂hn+1 + 2µ Q M (n)hn+1 = 0 (19)
The LMS algorithm is easily obtained from (19) by using the squared Euclidean distance

d [hn+1, hn] = hn+1 -hn 2 2 (20)
so that and from equation ( 19), we obtain that :

hn+1 = I + µQ M (n) -1 hn , (21)
but, according to the constraint :

h H n I + µQ M (n) -1 Q M (n) I + µQ M (n) -1 hn = 0 . ( 22
)
By using the first order approximation of the inverse matrix, the equation ( 22) will be :

h H n I -µQ M (n) Q M (n) I -µQ M (n) hn = 0 . ( 23
)
Therefor, the optimal step size µ is determined as a positive solution of the second order equation :

µ 2 -2aµ + b = 0 where a = h H n Q M (n) 2 hn h H n Q M (n) 3 hn and b = h H n Q M (n)hn h H n Q M (n) 3 hn

Adaptive SCR implementation

In the same way that in the adaptive standard CR implementation, the rewriting of the sparse CR criterion in adaptive case, leads to the following criterion :

J (h) = h H Q M (n)h + λ h p p , (24)
Therefore, the desired solution for h is determined by minimizing the mean value of this cost function and the LMS solution is given by the following adaptive solution :

hn+1 = hn -µ 2 Q M (n) hn + λ h ε n hn -µ 2 Q M (n) hn + λ h ε n 2 . ( 25
)
where

h ε n (i) = sign (hn(i)) (|hn(i)|+ε) p-1 for i = 1, . . . , M (L+1) , (26)
In this paper we consider only the case where (p, ε) ∈

(1, 0), (0, ε0) to avoid the non-convexity problem of the proposed criterion. For the NLMS approach in the case of sparse CR criterion, we assume the same development as in section 4.1 . By tackint into a count the sparsity penalty term, the new cost function can be express as :

L [hn+1] = d [hn+1, hn] + µ h H n+1 Q M (n)hn+1 + λ hn+1 p p
In the same way that shown is section 4.1 , in order to minimize L [hn+1] in the case squared Euclidean distance, we need to set its derivative

∂L[h n+1] ∂h n+1
to zero. Hence, the solution will be found by solving the equation

2 (hn+1 -hn) + 2µ Q M (n)hn+1 + λ hn+1 = 0 (27)
To avoid the divergence problem of the derivative of the p norm, we replace the hn+1 by h ε n+1 such as is define by equation (), and by using the following approximation h ε n+1 ≈ h ε n for (p, ε) ∈ (1, 0), (0, ε0) , we obtain that :

hn+1 = I + µQ M (n) -1 hn - λ 2 h ε n , (28)
and according to the CR constraint ;

hn - λ 2 h ε n H I+µQ M (n) -1 Q M (n) I+µQ M (n) -1 hn - λ 2 h ε n = 0
(29) and we can find easely from the previous section that the optimal step size µ is a solution of

µ 2 -2 aµ + b = 0 where a = hn -λ 2 h ε n H Q M (n) 2 hn -λ 2 h ε n hn -λ 2 h ε n H Q M (n) 3 hn -λ 2 h ε n and b = hn -λ 2 h ε n H Q M (n) hn -λ 2 h ε n hn -λ 2 h ε n H Q M (n) 3 hn -λ 2 h ε n 5. SIMULATIONS
We present here some numerical simulations to assess the performance of the proposed algorithm. We consider a SIMO system with M = 3 outputs represented by polynomial transfer function of degree L = 32. The channel impulse response is a sparse sequence of random variables with Bernoulli-Gaussian distribution [START_REF] Zibulevsky | Extraction of a source from multichannel data using sparse decomposition[END_REF] :

f (hi) = piδ(hi) + (1 -pi) 1 2πσ 2 i exp -h 2 i /2σ 2 i
generated by the MATLAB function SPRANDN. We used the parameters pi = 0.1 and σi = 1. The input signal is a BPSK i.i.d. sequence of length T = 25000. The observation is corrupted by addition white Gaussian noise with a variance σ 2 chosen such that the SN R = h 2 σ 2 . Statistics are evaluated over Nr = 100 Monte-Carlo runs and estimation performance are given by the normalized mean-square error criterion :

N M SE = 1 Nr Nr r=1 min α α hr -h 2 h 2 = 1 Nr Nr r=1 1 - h H r h hr h 2 ,
where hr denotes the estimated channel coefficient vector at the r th Monte-Carlo run and α is a scalar factor that compensates for the scale indeterminacy of the BSI problem. For the SCR algorithm, we used SCR1 and SCR2 for the SCR algorithm with the parameters (p, ε) = (1, 0) and (p, ε) = (0, ε0) respectively.

[1] G. Xu, H. Liu, L. Tong, and T. Kailath, "A least-squares approach to blind channel identification," IEEE Transactions on Signal Processing, vol. 43, no. 12, pp. 2982-2993, December 1995.

[2] L. Perros-Meilhac, E. Moulines, K. Abed-Meraim, P. Chevalier, and P. Duhamel, "Blind identification of multipath channels : a parametric subspace approach," IEEE Transactions on Signal Processing, vol. 49, no. 7, pp. 1468-1480, July 2001.

Fig. 1 .

 1 Fig. 1. Comparison of convergence between the CR and SCR adaptive algorithms for the three-channel system at 20 dB SNR.

Fig. 2 .

 2 Fig.2. Comparison of convergence between the CR and SCR adaptive algorithms for the three-channel system at 50 dB SNR.

Fig. 3 .

 3 Fig.3. Comparison of convergence of the SCR2 adaptive algorithms for the three-channel system at 50 dB SNR with the true channel order and overestimated channel order.

Fig. 4 .

 4 Fig. 4. Comparison of convergence of the SCR2 adaptive algorithms for the three-channel system at 50 dB SNR with different channel order.