Security properties in an open peer-to-peer network

International Journal of Network Security & Its Applications (IJNSA), Vol.1, No.3, October 2009 S ECURITY P ROPERTIES IN AN O PEN P EER - TO -P EER N ETWORK Jean-François Lalande, David Rodriguez, Christian Toinard Laboratoire d’Informatique Fondamentale d’Orléans Université d’Orléans – Ensi de Bourges 88 Bd Lahitolle, 18000 Bourges, France jean-francois.lalande@ensi-bourges.fr david.rodriguez@ensi-bourges.fr christian.toinard@ensi-bourges.fr Abstract This paper proposes to address new requirements of confidentiality, integrity and availability properties fitting to peer-to-peer domains of resources. The enforcement of security properties in an open peer-to- peer network remains an open problem as t he literature have mainly proposed contribution on availability of resources and anonymity of users. That paper proposes a novel architecture that eases the administration of a peer-to-peer netw ork. It considers a network of safe peer-to-peer clients in the sense that it is a commune client software that is shared by all the participants to cope with the sharing of various resources associated with different security requirements. However, our proposal deals with possible mal icious peers that attempt to compromise the requested security properties. Despite the safety of an open peer- to-peer network cannot be formally guaranteed, since a end user has privileges on the target host, our solution provides several advanced security enforcement. Fir st, i t enables to formall y define the requested securit y properties of the various shared resources. Second, it evaluates the trust and the reputation of the requesting peer by sending chall enges that test the fairness of it s peer-to-peer security policy. Moreover, it proposes an advanced Mandatory Access C ontrol that enforces the required peer-to-peer security properties through an automatic proj ection of the requested properties onto SELinux policies. Thus, the SELinux system of the requesting peer is aut omatically configured with respect to the required peer-to-peer security properties. That solution prevents from a malicious peer that could use ordinary applications such as a video reader to access confi dential files such as a video requesting fee paying. Since the malicious peer could try to abuse the system, SELinux chall enges and traces are also used to ev aluate t he fairness of the requester. That paper ends with different researc h perspectives such as a dedicated MAC system for the peer-to-peer client and honeypots for testing the security of the proposed peer-to-peer infrastructure. K EYWORDS Peer-to-peer, security properties, SELinux 1. I NTRODUCTION Historically, peer to peer softwares have been used to exchange files in order to by pass the limitations of centralize d solutions. New problems ari se when using peer to pe er clients. First, the usage of these software are commonly associated to the idea t hat these exchanges are illegals, regarding the cop y right violation [16]. If a user publishes a cop y righted file, the peer- to-peer system cannot prevent the spread of this file. Sec ond, the peers are supposed to respect security requirements in order to guarantee some fairness in the network. For example, a peer is not supposed to download files without sharing its own files. 73 International Journal of Network Security & Its Applications (IJNSA), Vol.1, No.3, October 2009 Security properties, i.e. confide ntiality, integrit y , availability are partiall y addressed in the literature. The focus is limited to the availabilit y and c onfidentiality properties. The existing peer-to-peer architect ures tr y to hi de the user’s activit y in order t o obtain a good level of anonym ity. Moreover, the resources must remain available in t he peer-to-peer network e ven if peers are faulty or try to abuse the protocol. On the contrary, the integrity property is poorly addressed: most of the papers consi ders integrit y as the ability t o transfer a file and to guarant y that it is identical to t he original resource. But in pr actice, the user needs to spe cify how the y want to share the resources in a m ore flexible way. Moreover, different security policies are required for various domains of usage. This pape r proposes a way to specify and enforce a flexible policy in order to allow the users to manage the required securit y properties in a peer-to-pe er network. It covers properties such as confidentiality (the resource of a community is shared and stays in t his co mm unity), integrit y (some resource t hat needs integrity must not be modified even if shared between us ers) and availability (t he resources that must be available must be spread over the peers). A new language is proposed for formalizing the requested security properties b y introducing the notion of do mains. That language enabl es to define the securit y polici es of the differe nt peers that can formally express their goals a bout the various resources they have. When conflicts appear between peers about the polic ies they have, a decision is ta ken by the resource’s holder to send or not the resour ce to the r equester. This paper s hows how the decision can be t aken using the analysis of the peer’s policies. If we consider a pe er-to-peer network where all the peers honor the protocol and respect the security policies, the properties attached to resources will be respected even if the r esources are exchanged in the n etwork. Of course, a peer-to- peer network coul d have malici ous peers t hat can tr y to abuse t he protocol, which is the main issue that is treated in the literature and described in section 2 . As our pr oposal is based on the negotiation of policies, the malici ous peers could cl aim a policy the y do not respect or ensure. Solutions for this problem are presented. It uses a r eal operating s y stem security enforcement and a distant evaluation of the conformity of the claim ed policy using various challenges and logs for both the peer-to-peer client and the operating system. A protot y pe of a peer-to-peer Java client have been implemented using the JXTA technology. It implements our negotiation protocol and the enforcem ent of t he requested policy through an automatic configuration of t he target SELinux s y stem. Si mulations of our negotiation protocol is presented and real use cases of our peer-to-peer client are given. 2. S TATE OF THE ART The a ncestors of distribut ed peer-to-peer s ystem s are sol utions with a ce ntralized index of published resources. A peer can request the server in order to find resources owned b y a peer it does not know. Then, the shared resource is exchanged from t he i dentified source to t he requesting peer. Other sol utions with clusters of servers increase the reliability of the solution as in Kazaa ne tworks. The next ge neration of peer-to-peer systems are totally distri buted [13]. The index of published resources is ensured by the peer s themselves [3, 6]. This avoids the reliability problem of the older peer-t o-peer sy stems but introduces a loss of control on the publication and the exchanges. Therefore, a strong effort has been done to hide activities of these peer-to-peer systems [1, 5, 6, 10], but it is a very limited notion of security. This section presents how the security is addressed in the lit erature of peer to peer systems. 2.1. Confidentiality and Anonymity The confidentialit y p roperty ha ve been interpreted in different wa ys in the literature. The first effort in the first peer-to-peer networks was focused on anonym ity of users [6, 7, 12], mainl y to escape censorship or to be protected when downloading copyrighted resources. T his anonymity 74 International Journal of Network Security & Its Applications (IJNSA), Vol.1, No.3, October 2009 is enforced by the protocol that allows the con tent of the m essage request to be encry pted to intermediary nodes. Seve ral versions of t his protocol [10, 6] have been proposed and are derivations of Chaum ’s mix protoc ol [4]. Another benefit of the encryption of the data is the integrity of the messages that can be verified b y the recipient peer. The use of relays can help t he intermediary nodes for their own anon ym ity. As they acts as relay s, the y can hide their own activities inside the rela y ed requests. I t becomes impossible t o know i f a node is acting for himself or for another nodes. This is called hiding or anti- censorship system [5]. The classical counter measure in case of a tentative of hiding is to analyze the traffi c flow of a node. An Internet Service Provider coul d tr y to analyze the IP packets in order to build a profile of the exchanged data [ 8]. The analysis could use i nformation suc h as used ports, TCP or UDP protocols, the amount of flow that is exchanged [18]. 2.2. Availability Another classical property t hat a pee r-to-peer s ystem tries to guarantee is the availability of the resources, mainly in case of fail stop fault. The t echnical solutions for t his issue rely on data replication: for example in GNUNet [11], the addresses and resources are duplicated on the neighbors of t he node respons ible of the resources. The resource’ s ownershi p is based on t he hashcode of the file: the peers are organized in a binar y tree and the file will be stored in the leaf whose binary number is the closest of t he hashcode. Then, t he neighbourhood will be the closest nodes of this leaf in the tree [3]. When a request is addressed to t he node that is known as the closest node of the resource, i t will eventually f orward the request to a node it knows closest. The requester obtains a pool of peers that are closed to the resource. This pool guar antees a good availability of the resource even in case of failure or disconnection. Other peer to peer file systems use different kind of DHT (Distributed hash ta ble) like Chord [9] that uses a ring distribution of peers or more sophisticated organizations like in Can [17] that uses a m ultidimensional s pace. These solutions ensure the same kind of availability. Performance storage or resource localization as well as management of files and their issues are outside the scope of this paper. 2.3. Integrity Several definitions of the integrity property exists. In [15] a comparison is done on the different definitions usually used. In peer-to-peer systems the integrity property can be inte rpreted as two different requirements: • the concept of data qualit y : the resources must meet or exceed the quality expected b y the user. • the prevention of unauthorized modification of data. For the data quality, the first peer-to- peer s y stems used metadata such a s test comments or t ags reported by the users. These r eports are diffic ult to evaluate and easily exploited by a malicious node, even if sophisticated correlation algorithms try to aggregate comm ents to identify the good resources and to exclude fakes. For the integrity of the exchanged data, t he protocols often co mbines anon y mity and verification when usi ng cryptographic ke y s to encr y pt t he requests and responses. One of the most known pr otocol that provides integrity of messages in ECRS [14] which is a variant of the CHK enc oding s cheme used in Freenet. The principle of ECRS is to provide a way to encr y pt the r esponse that will return from an unknown node to the initiator of the request. This way, the node that sent t he request can check that t he node that a nswered as reall y a resource that matches the request and ar e not a malicious node that have intercepted t he request and altered the information. 75 International Journal of Network Security & Its Applications (IJNSA), Vol.1, No.3, October 2009 Other peer- to-peer s y stems ha ve been proposed to manage the modification of a resource (OceanStore, Ivy and Pa stis). It can be seen as a sort of access control systems that all ows the publisher of t he r esource to con trol who is authorized to update t he resource. I n Pastis, the owner can dele gate the write per mission t o a group of peers. These proposals are the first steps of the integrit y property. T he fra mew orks are complex to deploy a s the y rely on cr y ptographic key s and signature s that have to be depl oy ed after havi ng authenticated the participating peer- to-peer nodes. 2.4. Discussion Existing solutions suffer from several major li mitations : • opened peer-to-peer networks cannot be controlled. I ndeed, each peer has local roo t privileges that authorize all the possible resource or pr otocol compromising. Thus, eac h peer can abuse the others about the enforcement of the securit y that it offers to the others. • they do not addr ess a dvanced securit y properties but onl y limited ones such as anonym ity, confidentiality and i ntegrity of messages. Integrity, confidentiality and availability of domains is missing. M oreover, relationships be tween the do mains is not addressed. • definition of s ecurity properties is not permitted. Thus, a peer cannot announce the proposed security policy. • evaluation of the enforcement of the proposed se curity polic y is not supported. So, attempts to abuse the system cannot be detected. • conflicts between distant security policies must be resolved in order to a uthorize the resource exchange. • finally, one cannot find an y model of trust that evaluates the reputation of a peer according to the requested security properties such as integrity and confidentialit y of domains. The following sections address those different li mitations in order to propose a new model to express and enforce a larger range of security properties in relation with various domains of usage. Moreover, evaluation strategies proposed to cope with conflicting but also malicious peers. 3. S ECURITY LANGUAGE Each peer can have a great nu mber of resources. To simplify their management, they are grouped t ogether into domains to which are applied a set of security propertie s. T he s ecurity policy of a peer is composed of all its domains a nd security properties. 3.1. Domains A domain d is defined as a unity of organization that groups multiple r esources which have the same set of securit y properties. The concept of domain is quite opened because it depends of the comm unit y that will define the domains. Our basic e xample is to consider t hree domains : a free domain, a fee paying domain, and a private company do m ain. The free domain defines a group of resources that can be exchanged without an y restriction. The fee pa y ing domain defines the resources that need t he payment of fees in order to have access to these resources. The pri vate domain defines privat e medias. When a res ource is published on the peer-to-peer network (it is t he first ti m e the resource is added), the resource is necessarily associated to a domain, as described later in secti on 3.4. 76 International Journal of Network Security & Its Applications (IJNSA), Vol.1, No.3, October 2009 3.2. Operation on domains A peer creates a domain when request ed by the user. A domain will contain downloaded resources and is empty at the beginning. The user will discover the existence of a domain, f or example on t he web, and will ask to the peer-to-peer client to create the domain. The deleti on of a useless domain can be requested by the user. In this case, all the resources of the domain should be dropped. 3.3. Security properties Integrity, confidentialit y and availabilit y are general properties which need to be adapted to peer to pe er networks. Indeed, they are full y opene d, decentralized and sometimes anon y mous, so it is a challenge to de fine and to insure a specific security p roperty for a given resource. Our architecture supports two kinds of properties : negative rules a nd positi ve rules which are prohibition properties and permission properties. 3.3.1. Prohibition properties Intuitively, a prohibition property can be “the resource must not change of domain” and a permission property “the resource is encouraged t o change of dom ain”. Prohibition properties are basicall y the removal of rights in the peer-to-peer network. B y default, a request ha ve t o be honoured because the goal of a peer-to-peer network is to exchange files between users. A policy that promotes prohibition prope rties tries to reduce the freedom of the users, in order to guarantee properties that are conflicting wit h the freedom property . Confidentiality The confidentia lity property expresses that the resources of a do main must be maintained in this domain over the peer-to-peer network. This is not the classical definition of the confidentiality propert y as it does not answer the question “who can access the resource over the peer-to-peer network ?”. T hat means t hat our goal is not to restrict the access of the r esource to a set of users (the user s are not known in adva nce in an open peer-to-peer network). Our goal is to guarantee that the resources sta y associated to the considered domain. confidentiality(d1) : no resources can exit do main d1. confidentiality(o1) : resource o1 must not exit its current domain. For example, the property is use ful for the fee pa y ing a nd a private company domain, t hat want that their files stay in their respecti ve domains: confidentiality(fee_paying) confidentiality(private_company_A) Moreover, the confidentiality property can be less restrictive if considering two dom ains that exclude each ot her: confidentialit y(d1, d2) : a resource of do main d1 must not be abl e to be written in domain d2. For exa mple, the pr operty is useful t o express that the fee pa y ing domain must not share resources that will reach the free do m ain: confidentiality(fee_paying, free) confidentiality(private_company_A, {free , fee_paying}) The c onfidentiality property does not prohibit a resource to be shared as long as it st ays in the same domain. Next, we introduce a property that prohibit t he sharing. No share prope rty The no share property expresses the need of pr ohibiting the s hare of t he resource with another pee r on the peer- to-peer network. The resource can eventually c hange of domain on the same pe er, but the peer must tr y to guaranty t hat the resource will not be sent to another peer. noshare(d1) : the resources in domain d1 must not be shared an y more. 77 International Journal of Network Security & Its Applications (IJNSA), Vol.1, No.3, October 2009 noshare(o1) : the resource o1 must not be shared an y more. This propert y can be used when a resource is sent by peer A to peer B in order to reque st that peer B does not share that resource. In this case, peer A allows peer B to get the resource but request the noshare property from peer B: noshare(movie_file) Integrity T he integrity pr operty aims to guaranty that the resources of a domain will not be modified by a peer. integrity(d1) : resources in domain d1 must not be modified. integrity(o1) : resources o1 must not be modified. For example, a PDF file is broadcasted over the peer-to-peer network and the author requires that the file will not be modified by an y peer that gets a copy of it: integrity(report.pdf) No publ ication The no publication property aims to guaranty that no resource will be published into a given domain. nopublication(d1) : no resource in domain d1 must be published. For example, a pe er can decide that the domain fee paying will onl y be used to download files and that it has no reason to publish files into t his domain: nopublication(fee_paying) 3.3.2. Permission properties The presented prohibition properties restrict t he f reedom of the users: the global polici es of the resources will beco me more and more strict. The worst case is the no share property that forbid definitively a peer to e xchange a resource. To counterbala nce these rules that can lead the sy ste m in a freezed state, we introduce permission properties t hat ca n be seen as positive properties t hat help the users to exchange files. This is a way to reenforce the freedom of users to share resources with its community. Cooperation Two com panies could be interested in setting up a strong cooperation between them. Each company can c reate a private domain and will probabl y use the confidentia lity property in order to protect their own data. In contrast, two domains can cooperate if the resources can easily be shared between them. cooperation(d1, d2) : all resources of domain d1 must be available for sharing into domain d2. cooperation(o1, d2) : resource o1 must be available for sharing into domain d2. For two companies A and B using private company A and private company B as do mains, the peers of these companies can setup these properties to authorize any sharing of private data: cooperation(private company A, private c ompany B) cooperation(private company B, private company A) Spread The spread prope rty is a generalization of the cooperation propert y . The idea of spreading a re source is t hat the owner of the resource wants the resource to be spread a s much as possible on the peer-to-peer network, copied into the sa me or other domains. spread(d1) : all resources of domain d1 must be available as much as possible and shared with other domains. 78 International Journal of Network Security & Its Applications (IJNSA), Vol.1, No.3, October 2009 spread(o1) : resource o1 must be available as much as possible and shared with other domains. For example, security patches could be spread on the domain kernel pat ch for the linux kernel: spread(kernel_patch) 3.3.3. Operation on properties There are two ways of updating securit y properties. A user can decide to add or remove a security propert y for a dom ain or a file. The second case is when the peer receives a request from the owner of a resource to modif y its pol icy. These two situations can generate conflicts of properties. 3.3.4. Conflicting properties Security properties can be added to a resource or to a domain. Eac h update can bring up a situation of conflicting properties. The table 1 shows if rule r1 can conflict wit h rule r2. In case of conflict, a decision must be taken to select one of the two rules or to perform more general modifications of the polic y . Table 1. Conflicting properties. r1 / r2 Conf. Integ. Spread No pub. No share. Coop. Confidentialit y x x Integrity Spread x x No publication No share x x Cooperation x x 3.4. Publication The publication of a resource can be done b y any peer in the system. When publishing a resource, the user chooses a domain where to drop it. The peer-to-peer client will check the policy in order to det ect a possible violat ion, f or example a nopubli cation rule concerning the targeted domain. When a user performs a publication, the domain’s file is not published across the net work bu t onl y the na me of t he file and i ts l ocation are se nt. The mechanism of storing and retrieving the resource ar e managed as in c lassical peer-to-pe er networks and are not addressed in this paper. Moreover, the peer wi ll eventuall y a dd new securit y properties for the considered re source to the local policy. The publication will ha ve this form: publish(security properties, resource, targeted domain) For example, when publishing a report, a user of company A will ask to the peer-to-peer client: publish({confidentiality, integrity}, re portA.pdf, private_company_A) The confidentialit y property is alrea dy ensured by the properties of domain pri vate company A in listi ng 1: t here is no need to add another confidentialit y property. For the integrit y property, a new rule integrity(reportA.pdf) will be added on peer A to get a satisfy ing security policy. Domains: free, fee paying, private_company_A 79 International Journal of Network Security & Its Applications (IJNSA), Vol.1, No.3, October 2009 confidentiality(fee paying) confidentiality(private company A) integrity(reportA.pdf) cooperation(private company A, private c ompany B) Listing 1. Domains and securit y properties of peer A. 4. P EER - TO - PEER NEGOTIATIONS The described security language allows a peer-to-peer client t o express the properties that he wants t o appl y on its resources. This is crucial for the resources that the peer wants to share on the network. But t his language is also used when two peers are negotiating for an exchange. The principles of a negotiation between a peer A (pA), owner of a resource, and an asking peer B (pB) is described in this section. 4.1. Negotiation basics First the peer pB sends a request to pA for a file on a target dom ain called dB. The a sked resource is situated in a domain dA that could be different of dB. In fact, two situations are possible: • The two peers know each other or have pre viously exchanged information about the domain they will use to share data. It means that both peers knows the string that will be used as domain’s name, i.e. dA = dB. • The two peers have never met before. It means that the peer pB does not know the name of the domain dA where is situated the resource r. As a consequence, dA ≠ dB. If dA = dB, the peer B have proba bly applied the same policy to the domain dB, to be consistent with pe er A. This way, the negotiati on will have the best chance to succeed, as t he peer A will have t he guarant y that t he polic y applied to its resource will sta y guara nteed when the resource will be exchanged with B. Nevertheless, e ven if t he domain’s names are t he same, t he policies applied to both domains could be different. Thus, pA will ask pB to send the part of its policy that is currentl y applied to t he domain dB. Indeed, the peer B as no r eason to send its whole poli cy to peer A. T he peer B does not want to reveal the rules that are applied to other domains he create d. Onl y the rules applied t o dB are needed in the negotiation because they will be associated to the resource after the exchange. The peer pA will be able to check if the received polic y hurts t he polic y attached t o the domain dA. For this purpose, t he Table 1 is used t o determine if one of the proposed propert y of domain db enters in conflicting with one of those of the domain dB. A basic decisi on is to decline the request of exchange if an y property of dB hurts a property of dA. This way , the peer pA i s su re to preserve the properties on the resources of dA. If the domain dA as no property , the peer cannot hurts the polic y of A and the peer pB is free t o propose a ny ne w prope rty on t he domain pB. T hus, a peer ha s the pos sibility to make evolve its policy for the considered resource: each pear, that requests a resource, can add a new propert y , if this propert y does not enter in conflict with the previous associated properties. For example, if a property spread(d) is attached t o a r esource, a peer will not be a ble to add the propert y confidentiality(d) because the peer that owns the resource will refuse the transfer. 4.2. Negotiation with malicious peers For pr operties that deal with security, we should evaluate if the pr oposal resists to attacks that try to defeat the se curity mechanisms. To defeat the mechanism, a malicious pe er can announce any security properties to the other peers. Nevertheless, two cases must be distinguished: 80 International Journal of Network Security & Its Applications (IJNSA), Vol.1, No.3, October 2009 • if the malicious peer have no i nformation about the properties associated with the requested resource, it will probably fail negotiating with the owner because the proposal will hurt the owner policy. • if the malicious peer knows precisel y what polic y is required f or the r equested resource, it can claim to ensure the same properties on the target domain, even if it will not honor those properties later on. Obviously, in a general manner, one can never prevent a m alicious peer to simulate a satisfying behaviour. However, simulating a correct behaviour beco m es difficult when the malicious peer: 1. must guess the requested policy, 2. is submitted to challenges 3. is automatically configured to enforce the requested policy using a MAC system such as SELinux that protects that peer at the Operating S y stem scale. The next section describes how to compute challenges and evaluate the accuracy of the response. 4.3. Evaluating the fairness of a peer 4.3.1. Evaluation of the proposed policy The proposed polic y could be evaluated regarding the possible confli cts with the requested policy . When the peer receives the proposed polic y from the requester, i t will check i f the proposed policy is conflicting with each propert y of the proposed policy : • -1 : the property is clearly violated by the polic y ; • 0 : the property is not provided by the polic y ; • 1 : the property is respected. A basic scenario is to sum the evaluations to obtain a global score. If positive, the global evaluation is positi ve. It means t hat m ost of the properties are respected by the requester of the resource and that some of them may be violated. 4.3.2. History The peer t hat owns the requested re source might ask a part of t he history fil e of the operations that the requester did. This is a wa y to check if the requester is re specting t he policy it proclaims. This log file could also be a fake log file, but it is a diffic ult t ask to pr ovide a fake log file that is coherent wit h all other parties i n a distributed systems. For example, a malicious peer can simulate the existence a nd transacti ons with a fake peer but the peer t hat evaluat es the history can check if the fake peer exi sts or has been viewed in the past. A proposal of eval uation of the history during a given time t is given below: • -1 : at least one log record indicates that the polic y has been violated during t; • -2 : the property has been violated before t; • 1 : no infraction has been viewed. Again, these fi gures can be combined to get a global score about the evaluation of the histor y file of the evaluated pe er. Evaluation of an histor y is reduced to the past. In order to have a real time vi ew of the reliability of requester, challenges are described in the following section. As detailed in the sequel, our archit ecture enforces the requested pe er-to-peer security properti es using SELi nux polic ies. So, the history also includes some SELinux traces such as the SELinux trace corresponding t o the attempt to ope n a protected resource using a m alicious application 81 International Journal of Network Security & Its Applications (IJNSA), Vol.1, No.3, October 2009 e.g. vim for opening a confidential fil e. Further details will be given in the experimentati on section. 4.3.3. Challenges These challe nges are delegated to the peers t hat A trusts. T hus, it becomes more difficult for a malicious peer to answer accordingly to t he various pee rs bec ause it wil l t ry t o be consi stent with conflic ting chall enges. I n order to improve the e valuation, a trus ted peer C will first send conflicting requests t o peer B i n order to make it change its policy accordingly. For example, C will request the spread propert y that is conflicting with the conf identiality propert y requested by A for the same domain. Afterwards, C will send challenges to A for eva luating the response to the transfer challenges. The purpose of t hat paper is not to choose between the best way to evaluate the response to t he challenge, since various trust measurements exist i n the literature, but t o pr opose an overal l architecture that aims at reusing existing trust formulas to evaluate the response to challe nges. I n the sequel, si mulation runs present the evaluation of the challenges carried out by the trusted distant peers. Since our architecture enforces the requested peer-to-peer security properties using SELinux policies, the pr oposed challenges include some SELinux challenges such as t he request for the distant peer to tr y to open a protected resource using a malicious application e.g. vim for opening a confidential file. Further explanati on will be given in the sequel about those mechanisms. 4.3.4. Reputation The peer A computes t he evaluati ons, carried out during the challenge phase, in order to define a challenge for the requesting peer B. T hus, the various distri buted challenges enable t o compute an over all reputation for the r equesting peer B. Various m athematical m easurements from the literature can be reused to evaluate the reputation of a peer B. The purpose of that paper i s not t o choose be tween the best mathe matical formulas to evaluate the reputati on, but to give a global archite cture that can reuse effici ently the existing r eputation formulas. In t he sequel, simulation of reputation measurements are described. 5. E NFORCING THE SECURITY PROPERTIES AT THE OS LEVEL After the evaluation of t he securit y policy presented in the previous section, the remaining security pitfalls deal with the local atta cks carried out both at peer A and pe er B sides. Let us assume a corrupted web navigator that could tr y to read the pr otected resources fro m the resources of a peer-to-peer client. I n order to prevent from such attacks or securit y violations, the re quested peer-to-peer securit y polic y is projected onto a SELinux pr otection pol icy. T hus, the SELinux mandator y acce ss control mechanism helps to enforce the securit y polic y and prevents the web navigator to access to the protected resources but allows the peer-to-peer client to access it. So, the following enforcement is provided: • peer-to-peer domains are protected against malicious applications • external applicati ons, suc h a s a vide o reader, ar e prevented fr om vi olating t he requested peer-to-peer security policies, such as the confidential ity of video files. 5.1. Projection of the peer-to-peer security properties onto SELinux protection policies A dedicate d tool P2PtoSELinux has been developed to convert the peer-t o-peer securit y properties into consistent SELi nux polici es. That tool takes a peer-to-peer security polic y p2p_properties.xml as input and produces a SELinux polic y pol_selinux as output. 82 International Journal of Network Security & Its Applications (IJNSA), Vol.1, No.3, October 2009 The listing 2 shows an extract of a peer-to-peer policy file, defini ng a dom ain name called domainA associated to di fferent security properties and a resource corresponding to the file /root/secret.txt that belongs to do main A. T hat res ource has a dedicated propert y corresponding to the cooperation with another domain. T his policy is represented on fi gure 1. The security properties of dom ain A are listed and t he dedicated property is written inside the file. Each security property is linked to the domain that is concerned by the property. Listing 2. P2P XML Policy. Figure 1: Policy representation for the XML policy of listing 2 The listing 3 shows an extract of the resulting SELinux protection polic y produced b y the P2PtoSELinux tool. As one can see, a default policy is computed but also dedicated policies for the various security properties i.e. confidentiality , integrity , no publication, no s hare, cooperation and sp read. Those protection policies lim it the perm ission for the corresponding resources. A peer-to-peer client will use the vari ous corresponding security cont ext according to the required domain. T hus, a confidential r esource will be labelled with the Confidentiality SELinux context. Usually, the Confidentialit y context cannot be read by any external application such as a video reader since it does not have the required privileges. However, a video re ader ca n pla y a resource protected b y the Confidentialit y context if i t has a s atisfying SELinux subject context. I n order for t he end users to r ead confidential infor mation, they must have the corresponding privileges and the applica tion must transmit to a satisfying SELinux subject in order to be able to read that information. Default: allow file {read write unlink create appe nd mounton rename lock execute geattr setattr} allow dir {read write unlink search crea te mounton getattr setattr rename add_name remove_name r eparent rmdir} Confidentiality: Default + neverallow file {read append setattr} neverallow dir {read search setattr} 83 International Journal of Network Security & Its Applications (IJNSA), Vol.1, No.3, October 2009 Integrity: Default + neverallow file {write unlink append rename se tattr} neverallow dir {write unlink setattr rename remove_name rmdir} No publication, NoShare: Default + neverallow file {create setattr mounton} neverallow dir {create setattr add_na me remove_name rmdir mounton} Cooperatoin, Spread: Default Listing 3: SELinux rules 5.2. Obtained SELinux protection The listing 4 shows the trace of a SELinux c ontrol associate d with the editor vi m atte mpting to read the file s ecret.txt that is protected b y the peer-to-peer Confi dentiality property. T he SELinux context s y stem_u:object_r:do mainA_t associated to the secret.t xt file prevents the vi m application from the reading access. So, that e xample shows that an e xternal application such as vim cannot violate the corresponding peer-to-peer Confidentiality property . Thus, the proposed so lution enforces the security of the request ed properties within the local machine, since a malicious external application fails to compromise the peer-to-peer security properties for the local peer-to-peer resources. audit(1229395253.757:369): avc: denied { read } f or pid=4241 comm="vim" name="secret.txt" dev=sda3 ino=179226 scontext=user_u:use r_r:user_t tcontext=system_u:object_r:domainA_t tcla ss=file Listing 4: SELinux control 6. I MPLEMENTATION AND EXPERIMENTATION We are c urrently worki ng on the i mplem entation of a peer-to-peer network which can answer the requirements of the model of secti on 3. A first Java si m ulation of the protocol and trust computation has be en released. Moreover, a first i mplementation of a peer-to-peer client is currently available. The user interface will be presented in the second subsection in order to show the us age of the security proper ties. That interface is a front end for the P2PtoSElinux tool. T hus, the peer-to-peer securit y properti es r equested by the end user are a utomatically projected onto SELinux, protecting the target system from the corruption of the other applications. 6.1. Trust simulation Listing 5 shows the si mulation code that setup two peers JFL and Dav id. Davi d asks the file “contract” to pe er JFL that have the confide ntiality propert y on the “ensib” do main. David claims to put the file in the free do m ain whic h ensures the spread property . Listing 6 shows the resulting ne gotiation bet ween peer J FL and David. It shows the details of the computati on of the T rust value (Tv) f or the two re quired properties for the domain “ensib” against the David policy using its history and chall enges: T v(integrity,David) equals 0.38 and Tv(confidentiality,David) equals 0 for the domain “ensib”. This la st value forces JFL to refuse the resource exchange, because of the value of a fixed threshold (0.2). // Creating peers, domains, files on JFL side Domain ensib = new Domain("ensib"); Domain free = new Domain("free"); Resource firefox = new Resource("firefox"); Resource contract = new Resource("c ontract"); Peer jf = new Peer("JFL"); Peer pc1 = new Peer("C"); Peer pc2 = new Peer("C"); // Initiating the reputation of peer JF jf.knows(pc1,0.8); 84 International Journal of Network Security & Its Applications (IJNSA), Vol.1, No.3, October 2009 jf.knows(pc2,0.9); // Adding resource in domains jf.add(firefox, free); jf.add(contract, ensib); // Applying security properties on domains Property confid = new Property("confidentiality"); Property integ = new Property("integrity"); Property coop = new Property("cooperation"); jf.add(confid, ensib); jf.add(integ, ensib); jf.add(coop, free); // Creating peers, domains, files on Da vid side Domain free2 = new Domain("free"); Property spread = new Property("spread") ; Peer david = new Peer("David"); david.add(spread,free2); // Simulation jf.affiche(); david.affiche(); david.ask(jf, "c ontract", "free"); Listing 5: Example of simulation code [Display JFL] ensib secured by [confidentialit y, integrity] [Display JFL] contract in ensib under [confidentiality, integrity] [Display JFL] firefox in free under null [Display David] free secured by [spread] David: I asks to peer JFL the file contrac t to be put in free JFL: Peer David asking file contract JFL: Peer David will put the file in domain f ree JFL: File contract found. JFL: File is in domain ensib JFL: Security properties [confidentialit y, integrity] David: someone asking policy for domain free David: returning policy [spread] (Eval) JFL Computation of Eval(David,confidentiality) (Eval) JFL Target domain has property spread (Eval) JFL the properties of David's free domain hurts the required property confidentiality (Eval) Eval(David,confidentiality)=-1 (Eval) Hist(David,confidentiality)=2 (Eval) Chal(confidentiality,David)=0.4 (Eval) EvalHist(confidentiality,David)=0.0 (Eval) Tv(confidentiality,David)=0.0 (Eval) Peer refused (0.0<0.2) for c onfidentiality trust decreased to 0.48 (Eval) JFL Computation of Eval(David,integrity) (Eval) JFL Target domain has property spread (Eval) Eval(David,integrity)=0 (Eval) Hist(David,integrity)=2 (Eval) Chal(integrity,David)=0.7266666666666667 (Eval) EvalHist(integrity,David)=0.5 (Eval) Tv(integrity,David)=0.38524635476491 (Eval) Peer not fully trusted (0.2<0.38524635476491<0.5) for integrity trust decreased to 0.47 JFL: one of the property is refused: refusing request. David: peer JFL REFUSED to send the file. Listing 6: Example of negotiation A se cond example i s given in listings 7 and 8. This time, the resource firefox is asked by David that declares to put it in domain “free”. As the cooperation property does not hurt the s pread property , the com putation of T v(cooperation,David) gives 0.44 that is s ufficient to allow the resource exchange (greater than the fixed threshold 0.2). //david.ask(jf, ”contract”, ”free”) ; david.ask(jf, ”firefox”, ”free”); Listing 7: Firefox asked by David [Display JFL] ensib secured by [confidentialit y, integrity] 85 International Journal of Network Security & Its Applications (IJNSA), Vol.1, No.3, October 2009 [Display JFL] free secured by [cooperation] [Display JFL] contract in ensib under [confidentiality, integrity] [Display JFL] firefox in free under [c ooperation] [Display David] free secured by [spread] David: I asks to peer JFL the file firefox to be put in free JFL: Peer David asking file firefox JFL: Peer David will put the file in domain f ree JFL: File firefox found. JFL: File is in domain free JFL: Security properties [cooperation] David: someone asking policy for domain free David: returning policy [spread] (Eval) JFL Computation of Eval(David,cooperation) (Eval) JFL Target domain has property spread (Eval) Eval(David,cooperation)=0 (Eval) Hist(David,cooperation)=2 (Eval) Chal(cooperation,David)=0.8500000000000001 (Eval) EvalHist(cooperation,David)=0.5 (Eval) Tv(cooperation,David)=0.44243254304683094 (Eval) Peer not fully trusted (0.2<0.44243254304683094<0.5) for cooperation trust decreased to 0.49 JFL: request accepted. David: peer JFL accepted to send the f ile. Listing 8: Negociation for Firefox 6.2. Peer-to-peer client managing security properties A peer-to-peer client has been developed using a JXTA module that provides peer-to-peer primitives (file t ransfer, conne ction of new clients). The figure 2 shows t he graphical interface of the client. It allows to edit the se curity policy of the local do m ains and files. The lower l eft window shows the shared files and the domains as sociated to t hose files. The right side enables to change the security property associated to the file or t o the do main. The upper window shows the distant shared files or the results of a specific string search. Figure 2. Graphical interface of the peer-to-peer cli ent Configuration of the requested security properties is easy through that user interface. Moreover, the trust algorithm is completel y transparent to the end user. 6.3. P2PtoSELinux performances The figure 3 shows how the execution time evolves according to the number of consi dered domains. For 10 domains, P2PtoSEl inux takes 1.67 seconds to compute the correspondi ng SELinux policy. For 640 domains the execution t ime takes 2.736 seconds. So, the co mputation time is linear with the number of considered dom ains when considering more than 100 domains. 86 International Journal of Network Security & Its Applications (IJNSA), Vol.1, No.3, October 2009 Figure 3: Execution time according to number of domains 6.4. SELinux challenges and traces As presented p reviously our architecture uses SELinux traces and challe nges to e valuate the trust and r eputation of the requester. Let us give some examples of the produced challenges and traces associat ed with the target resource secret.txt. When a peer B requests a resource associated with domainA, peer B sends its peer-to-peer se curity polic y corresponding to its target do main such as presented in listing 2. T hus, a trusted peer C se nds to B a challenge such as defined in listing 9 i n order to request the peer-to-peer client to execute the vim /root/secret.txt command us ing t he subject SELinux context user_u:user_r:user_t. If the pe er-to- peer client that is executed onto B is safe, it should answer with a failed SELinux trace such as presented in listing 4. scontext=user_u:user_r:user_t vim /root/secre t.txt Listing 9. SELinux control 7. P ERSPECTIVES The enforcement of the proposed securit y properties brings several new perspectives. First, conflicting security properties will bring conflicting SELinux policies, which is not acceptable for SELinux. A decision engine have to decide how to resolve those conflicting policies. Second, a MAC mechanism could be integrate d within the peer-to-peer client itself. That dedicated MAC m echanism would prevent from illegal flows inside a peer-to-peer client in order to deal with a corrupted peer-to-peer client. This MAC mechanism could be based on the JAAS module provided by the Java virtual machine that allows to control the access to the resources of the system such as the network or the files. Thus, two levels of access control could be setup: one fine grained access control could be applied at the software level, and one strongest access control at the OS level. Finally, large scale experim ental results are planned in order to evaluate the protocol’s robustness. Different experiments will bet setup. Fi rst, a simulation of a large net work of peers will permit to introduce a malicious peer that wi ll viol ate the polic y it claims. This will allow to analyze i f the system behave well i n a large sy stem with t housands of peers. Second, experiments are planned based on our experience i n high i nteraction hone y pots [2] where compromised hosts are observed in order to analy ze attackers behaviours. A peer-to-peer honey pot will be setup to invite attackers to t ry to get resources of the parti cipants, protected by security properties. This experiment could help to improve the securit y of the proposed solution analysing the attacks in a real peer-to-peer network. A CKNOWLEDGEMENTS 87 International Journal of Network Security & Its Applications (IJNSA), Vol.1, No.3, October 2009 This pa per was supported b y the work of several engineering students in computer sciences for their master degr ee from Ensi of Bourges, France: Virginie Klein, Fabien Le Solliec, David Rosa, Michael Souchet. R EFERENCES [1] Androutsellis-Theotokis, S. & Spi nellis, D. (2004) “A survey of peer-to-peer content distribution technologies”, ACM Computing Surveys (CSUR) , Vol. 36, No. 4, pp. 335-371. [2] Briffaut, J ., Lalande, J.-F., & Toinard, C. (2009) “Security and results of a large-scale h igh- interaction honeypot”, Journal of C omputers , Special Issue on Security and High Performance Computer Systems, Vol. 4, No. 5, pp. 395–404. [3] Brunner, R. (2006) “A performance evaluation of the kad- protocol”, Master’s thesi s, Universit y of Mannheim and Institut Eurecom. [4] Chaum, D. L. (1981) “Untraceable electronic mail, return addresses, and digital pseudonyms”, Communications of the ACM , Vol. 24, No. 2, pp. 84–90. [5] Grothoff, C., Grothoff, K., Horozov, T., & Lindgren, J. T. (2003) “An Encoding for Censorhip- Resistant Sharing”, Technical report. [6] Clarke, I., Miller, S. G., Hong, T. W., S andberg, O., & W iley, B. (2002) “Protecting free expression online with freenet”, IEEE Internet Computing , Vol. 6 No. 1, pp. 40–49. [7] Clarke, I., Sandberg, O., Wiley, B., & W.Hong, T. (2000) “Freenet: a distributed anon y mous information storage and retrieval system”, In International W orkshop on Design Issues in Anonymity and Unobservability, pp. 311–320. [8] Ernesto (2007) “Comcast throttles bittorrent traffic, s eeding impossible”, World Wide Web electronic publication. [9] Stoica, I., Morris, R., Karger, D., Kaashoek, M . F., & Balakrishnan, H. (2001), “Chord: A scalable peer-t o-peer lookup service for internet applications”, Technical report, New York, NY, USA, pp. 149-160. [10] Bennett, K. & Grothoff, K., (2002). GAP - pratical anonymous networking . Technical report, Departement of Computer Sciences, University of Purdue (USA). [11] Bennett, K., Grothoff, C ., Horozov, T., P atrascu I ., & Stef, T. (2002) “GNUN ET - A truly anonymous networking infr astructure”, Tec hnical repor t, Departement of Computer Sc iences, Purdue. [12] Kügler, D. (2003) “An analysis of Gnunet and the implications for anonymous, censorship- resistant networks”, In Proceedings of the 3rd I nternational Workshop on P rivacy Enhancing Technologies, pp. 161–176, Springer-Verlag. [13] Maymounkov, P., & Mazieres, D. (2002) “Kademlia: A peer-to-peer information s y stem based on the XOR metric”, In International W orkshop on P eer-to-Peer Systems ( IPTPS), LNCS, Vol. 1. [14] Dingledine, R., Freedman, M. J., & Molnar, D. (2000) “The Free Haven Project : Distributed Anonymous Storage Service”, Technical report, MIT and Harvard. [15] Sandhu, R. S. (1994), “On five definitions of data integr ity”. I n The I FIP WG11.3 Working Conference on Database Security VII, Amsterdam, The Netherlands: North-Holland Publishing Co, pp. 257–267. [16] Sherman, C. (2000), “Napster: Copyright k iller or distribution hero?”, Online , Vol. 24, No. 6, pp. 6-28. [17] Ratnasamy, S., Francis, P., Handley, M., Karp, R ., & Schenker, S. (2001) “A scalable content- addressable network”, In S IGCOMM’01: Proceedings of the 2001 conference on Applications, technologies, architectures, and protocols for computer communications, New York, NY, USA: ACM, pp. 161–172. 88 International Journal of Network Security & Its Applications (IJNSA), Vol.1, No.3, October 2009 [18] Wagner, A., Dubendorfer, T., Hammerle, L., & Plattner, B. (2006) “Flow-based identification of p2p heavy-hitters”, In ICISP’06: Proceedings of the International Conference on Internet Surveillance and Protection, Washington, DC, USA: IEEE Computer Society , pp. 15. 89