• Aucun résultat trouvé

List of tables

2. Architecture: elements of a secure P2P data storage system

2.4. Application layer

The application-level layer is concerned with the service that is installed at each peer machine. A peer should store other peers’ data and keep them available for them. Additionally, it should correctly answer verifiers’ challenges based on the stored data.

2.4.1. Shared storage management

In the proposed P2P data storage application, the shared resource is the extra storage space spared at each peer that is used to set up a remote data storage facility.

The common technique to provide data reliability is realized by disseminating the data into multiple copies in the network. Data redundancy can be implemented through either replication or erasure coding. With replication, the copy is a simple duplicate of the data. Whereas, erasure coded copies are coded blocks such that any threshold sized set of these blocks allows generating the original data. Redundancy entails that the size of the actual consumed storage space is larger than the data size. The overhead introduced by data redundancy can however be coped with. For instance, Wuala41 reduces the remote storage space allocated to a peer in exchange of an equivalent local storage space based on its probability of being online: the unallocated storage space serves for trading space on other peers in order to achieve a redundant storage [Toka and Michiardi 2008].

The preservation of the remote data is handled by their holders. The management of the shared storage falls then directly in the individual sphere of the holder, thus corroborating the idea of peer cooperation as a requirement for this type of storage system.

Verifiers, which are delegates of the data owner, operate a double check on the remote storage. The data holder should correctly respond to periodic verifier challenges and also send back the data whenever their owner wants to retrieve them.

Providing data availability and survivability is not just the concern of their owner. Several holders and verifiers contributed to this task. The distribution of the work to multiple peers limits the selfishness of holders or verifiers.

Peer cooperation in providing storage resources is stimulated through the trust and cooperation layer (discussed in the previous section). The fairness of peer contributions is particularly regulated by the cooperation incentives that work as a quota system: peers consume

41http://wua.la/en/home.html

storage resources from the system because they contribute such resources to other peers. Other type of resource utilization (e.g., bandwidth) related for instance to the performing the verification task must also be stimulated and regulated.

2.4.2. Multi-service framework

There is a potential interest in providing a general framework of cooperative services instead of one specific to P2P storage, mainly in case where a peer desires to store data in the P2P network without sacrificing its own storage space. This situation may be rendered possible by just making the peer contribute to the community of peers with other resources that it has in abundance. The P2P storage service may be then combined with other resource sharing services that relate for example to the bandwidth (file sharing), computation, or even networking. Each peer participates to a collection of services which the peer retains some of them for consumption and others for contribution.

Payment-based approach

Remuneration (e.g., real/virtual money, token) can be regarded as a neutral counterpart that can be traded for any cooperative service. Therefore, a system based on payment-based cooperation incentives is able to allow peers simultaneously accessing multiple cooperative services (e.g., remote storage, cloud computing, distributed database).

The evaluation of the good behavior of peers should be performed separately and independently using verification mechanisms specifically designed for each service.

However, the remuneration for a service can be operated with the same manner. For instance, remuneration may rely on auctions (like in the KARMA framework [Vishnumurthy et al. 2003]) to better cope with the effect of changes in supply and demand on service prices.

Each peer contributing with a service might first auction the offered service and then supply the service to the winning bidder. The service delivered by the peer would then be checked to evaluate whether it corresponds to the advertised offer. Such an evaluation permits to determine if the service provider is worthy of the remuneration earned in counterpart to the service (cf.

Figure 9).

Trusted OS based approach

Additionally, peer cooperation in a multi-service framework can be enforced through the use of trusted OS. Each peer’s device incorporates a trusted OS that controls the access of the peer to resources and services and may exploit such control to stimulate or even force the peer to cooperate to the P2P system in a strictly fair manner. The cooperation enforcement may be illustrated through service differentiation: a cooperative peer will have a good quality of service (e.g., high bandwidth) and a non cooperative peer will have a bad quality of service (e.g., intermittent connection to the P2P network).

Figure 9 Multi-service framework based on payment

Data storage verification would thus serve two different functions:

- Peer evaluation: Based on peer assessments, the framework computes and maintains a counter that reflects the degree of peer cooperation. The counter employs different weights for resources.

- Service differentiation: The framework makes use of the counter as an indicator of the level of quality of service that the peer deserves. Based on the value of the counter, peer services are either upgraded or degraded and such service differentiation is enforced through the trusted OS.

The peer evaluation function of the framework requires the employ of a remote data possession verification protocol to check the fair and correct storage sharing between peers. The verifier for such protocol may correspond to a service implemented within the trusted

“userland” part (not the kernel) of the trusted OS.

To be able to design the framework, we may use the cooperation counter as a context information modifying a dynamic access control policy: any change in the value of the counter would result in a change in the access rights to services granted to the user.

Alternatively, we may make use of the Flask security architecture [Spencer et al. 1999] as used in the SELinux (Security-enhanced Linux) operating system to enforce the security policy in a flexible way. Such a security architecture (see Figure 10) divides the responsibility for security into an object manager part and a security server part. The object manager controls every object invocation by checking every object request through the security server. This latter contains a complete representation of the security policy. With such an architecture, the security policy is consulted for every security decision, and thus can manage the revocation of previously granted access rights. For instance, let us consider a user that had previously access to a given service but who was in the meanwhile uncooperative. His cooperation counter will be

diminished until reaching the point where the access to the very service will be revoked to him in its subsequent object (service) request.

Figure 10 The Flask security architecture

2.5. Summary

This chapter describes the many elements of an architecture adapted to the secure P2P storage problem. The most important elements of this architecture are the overlay and trust management elements. We have identified techniques of management and implementation of the blocks that make up these layers and particularly how they may be enforced with a trusted environment.

The chapter describes several ways in which our cooperation incentive mechanisms may benefit from a trusted environment in order to improve peer behavior evaluation and motivate or enforce the cooperation of peers and the fairness of their contributions.

Finally, we described how it would be possible to design a multi-service framework based on trusted OSes for offering peers the opportunity to select the resources that they prefer to contribute in order to cope with the use of heterogeneous resources, capabilities, and needs.

Although the use of trusted environment may make deploying our mechanism more costly, this would of course be mitigated by the deployment of more efficient security measures. The rest of the thesis studies how to ensure a correct operation of the P2P storage system by relying solely on peers, in particular based on remote data possession verifications.

Chapter 3