25.01.2014 Views

Security Threats in Volunteer Computing Environments Using the ...

Security Threats in Volunteer Computing Environments Using the ...

Security Threats in Volunteer Computing Environments Using the ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Paulo Picota Cano et al ,Int.J.Computer Technology & Applications,Vol 3 (3), 944-948<br />

ISSN:2229-6093<br />

<strong>Security</strong> <strong>Threats</strong> <strong>in</strong> <strong>Volunteer</strong> Comput<strong>in</strong>g <strong>Environments</strong> Us<strong>in</strong>g <strong>the</strong> Berkeley<br />

Open Infrastructure for Network Comput<strong>in</strong>g (BOINC)<br />

Paulo Picota Cano<br />

Universidad Tecnológica de Panamá<br />

Research Center <strong>in</strong> Information and Communications<br />

Technology, CIDITIC<br />

paulo.picota@utp.ac.pa<br />

Miguel Vargas-Lombardo<br />

Universidad Tecnológica de Panamá<br />

Research Center <strong>in</strong> Information and Communications<br />

Technology, CIDITIC<br />

miguel.vargas@utp.ac.pa<br />

Abstract<br />

<strong>Volunteer</strong> Comput<strong>in</strong>g is a low cost and easy deployable<br />

solution for scientific projects that require large amounts<br />

of computational power. <strong>Volunteer</strong> comput<strong>in</strong>g public<br />

access capabilities comes with several security threats to<br />

<strong>the</strong> projects, thus, this projects must be designed and<br />

focused towards security <strong>in</strong> order to be able to stand<br />

aga<strong>in</strong>st this threats. The follow<strong>in</strong>g paper presents a<br />

summary of <strong>the</strong> security threats identified <strong>in</strong> volunteer<br />

comput<strong>in</strong>g environments deploy<strong>in</strong>g <strong>the</strong> Berkeley Open<br />

Infrastructure for Network Comput<strong>in</strong>g (BOINC) and some<br />

solutions implement<strong>in</strong>g Sanbox<strong>in</strong>g Techniques on<br />

distributed comput<strong>in</strong>g environments.<br />

Keywords: BOINC; security; <strong>Volunteer</strong> Comput<strong>in</strong>g;<br />

sandbox; virtual mach<strong>in</strong>e<br />

1. Introduction<br />

In scientific computational projects, <strong>the</strong> volunteer<br />

comput<strong>in</strong>g work model presents a solution to projects that<br />

have low resources to access to large amounts of<br />

computational power [1]. In volunteer comput<strong>in</strong>g, a server<br />

conta<strong>in</strong>s a project that can be accessed and many users<br />

voluntarily provide comput<strong>in</strong>g resources (process<strong>in</strong>g time,<br />

memory, disk space) whenever <strong>the</strong> user’s computer is <strong>in</strong><br />

idle state. This users are known as volunteers and <strong>the</strong>ir<br />

computers are known as host to <strong>the</strong> project to which <strong>the</strong><br />

user is provid<strong>in</strong>g <strong>the</strong> resources.<br />

The Berkeley Open Infrastructure for Network<br />

Comput<strong>in</strong>g (BOINC) [1] is a volunteer computer platform<br />

that provides def<strong>in</strong>ed strategies to prevent and counteract<br />

security threats, on both malicious volunteers and external<br />

attackers [2]. On <strong>the</strong> follow<strong>in</strong>g paper we present different<br />

techniques designed to prevent security threats such as<br />

code sign<strong>in</strong>g and public-asymmetric cryptography.<br />

The use of host-<strong>in</strong>dependent environments, known as<br />

sandbox, will be presented with <strong>the</strong> advantages that this<br />

host-<strong>in</strong>dependent technique provides to <strong>the</strong> volunteer<br />

project.<br />

This paper is organized as follows: section II<br />

<strong>in</strong>troduces <strong>the</strong> different security threats to volunteer<br />

comput<strong>in</strong>g, section III discusses sandbox<strong>in</strong>g techniques and<br />

<strong>the</strong>ir advantage towards volunteer comput<strong>in</strong>g security, <strong>in</strong><br />

section IV it is presented an approach to apply sandbox and<br />

virtual mach<strong>in</strong>es <strong>in</strong> computational grids called m<strong>in</strong>imum<br />

<strong>in</strong>trusion grids, section V presents a proposal to design a<br />

framework for BOINC projects focus<strong>in</strong>g <strong>in</strong> virtual<br />

mach<strong>in</strong>es as sandbox appliance, f<strong>in</strong>ally section VI gives<br />

<strong>the</strong> conclusions and fur<strong>the</strong>r work follow<strong>in</strong>g this paper.<br />

2. <strong>Security</strong> <strong>Threats</strong><br />

BOINC Project developers group have identified a<br />

series of possible security threats for projects runn<strong>in</strong>g on<br />

volunteer comput<strong>in</strong>g networks [2]. This security threats<br />

have been taken <strong>in</strong> consideration along with <strong>the</strong><br />

development and improvement of <strong>the</strong> BOINC platform.<br />

BOINC hasn’t reported any <strong>in</strong>cidents regard<strong>in</strong>g <strong>the</strong><br />

follow<strong>in</strong>g security threats, but that is very important for<br />

IJCTA | MAY-JUNE 2012<br />

Available onl<strong>in</strong>e@www.ijcta.com<br />

944


Paulo Picota Cano et al ,Int.J.Computer Technology & Applications,Vol 3 (3), 944-948<br />

ISSN:2229-6093<br />

every user and project developer to “keep an eye” on <strong>the</strong>m<br />

[3].<br />

We can summarize BOINC’s security issues as<br />

follows[2]:<br />

Results and credits falsification: <strong>Volunteer</strong>s might send<br />

<strong>in</strong>correct <strong>in</strong>formation regard<strong>in</strong>g data results or claim more<br />

CPU usage than <strong>the</strong>y are actually offer<strong>in</strong>g. The way to<br />

prevent this, BOINC [4] require that projects runn<strong>in</strong>g<br />

under it must have two rout<strong>in</strong>es: a validator, to confirm<br />

that <strong>the</strong> results will be valid and an assimilator to handle<br />

validated results. To validate, BOINC supports replication<br />

techniques, <strong>in</strong> which ra<strong>the</strong>r than mak<strong>in</strong>g each task one time<br />

only, <strong>the</strong> same task is assigned to multiple host computers.<br />

This way, <strong>the</strong> results can be validated <strong>in</strong> an easier way.<br />

Depend<strong>in</strong>g on <strong>the</strong> project, developers could use some<br />

ma<strong>the</strong>matical libraries to reduce to m<strong>in</strong>imum calculation<br />

discrepancies. In some projects where discrepancy could be<br />

tolerated, a measured tolerance level allows <strong>the</strong> developers<br />

to have a better reference on <strong>the</strong> results.<br />

Malicious executable distribution: An attacker could<br />

change <strong>the</strong> project’s content <strong>in</strong> order to distribute malicious<br />

code through <strong>the</strong> volunteer network. BOINC requires <strong>the</strong><br />

use of correctly implemented methods of code sign<strong>in</strong>g [3].<br />

The digital signatures apply a set of public-private keys.<br />

BOINC recommends to follow a series of steps to generate<br />

<strong>the</strong> key set and how to manage it accord<strong>in</strong>g to code sign<strong>in</strong>g<br />

policies [3].<br />

Overrun of data servers: An attacker could send large<br />

amounts of data overrunn<strong>in</strong>g <strong>the</strong> servers and disabl<strong>in</strong>g<br />

<strong>the</strong>m. To prevent <strong>the</strong>se sorts of attacks, BOINC provides a<br />

tool called “upload certificates” [2]. Each project def<strong>in</strong>es a<br />

maximum output file sizes and each project must have a<br />

unique identification key. When a set of output files are<br />

sent to <strong>the</strong> server, <strong>the</strong> file sizes is checked and verified and<br />

<strong>the</strong> au<strong>the</strong>ntication key is matched.<br />

Theft of participant account <strong>in</strong>formation by network<br />

attack: Attackers could get access to <strong>the</strong> BOINC servers<br />

and use network vulnerabilities to steal project or user<br />

<strong>in</strong>formation. The protection of <strong>the</strong> users and project<br />

<strong>in</strong>formation is to be taken care of by <strong>the</strong> project’s<br />

developer. BOINC requires that <strong>the</strong> servers must be<br />

protected accord<strong>in</strong>g to security standards implement<strong>in</strong>g<br />

firewalls and secure access protocols such as SSH.<br />

Theft of project files: An attacker could steal any of <strong>the</strong><br />

<strong>in</strong>put or output <strong>in</strong>formation of any project runn<strong>in</strong>g on<br />

BOINC. Although <strong>the</strong> generated files are not encrypted by<br />

default, BOINC project developers can apply any<br />

encryption technique upon <strong>the</strong>ir projects.<br />

Intentional or accidental abuse of participants hosts<br />

projects: Any rout<strong>in</strong>e might <strong>in</strong>tentionally abuse of a<br />

volunteer host by steal<strong>in</strong>g <strong>in</strong>formation or accidentally<br />

modify<strong>in</strong>g configuration files with<strong>in</strong> <strong>the</strong> host computer. To<br />

prevent this k<strong>in</strong>d of abuses, BOINC provide us with two<br />

very useful tools. The first uses sandbox<strong>in</strong>g to prevent <strong>the</strong><br />

project from access<strong>in</strong>g any files outside of <strong>the</strong> BOINC<br />

environment. The second technique detects <strong>the</strong> amount of<br />

resources be<strong>in</strong>g used by <strong>the</strong> project, if <strong>the</strong> project is tak<strong>in</strong>g<br />

too much disk space, memory or process<strong>in</strong>g time <strong>the</strong><br />

project will be closed.<br />

One way to guarantee <strong>the</strong> <strong>in</strong>tegrity of <strong>the</strong> <strong>in</strong>formation<br />

is us<strong>in</strong>g a not-<strong>in</strong>trusive security model that will allow easy<br />

deployment <strong>in</strong>dependent of <strong>the</strong> host platform. These<br />

work<strong>in</strong>g environments are with<strong>in</strong> <strong>the</strong> reach of <strong>the</strong> sandbox<br />

concept and represent a viable solution to many security<br />

threats.<br />

3. Sandbox: a solution to security issues<br />

Sandbox<strong>in</strong>g gives us an isolated environment, deny<strong>in</strong>g<br />

<strong>the</strong> project application any access to <strong>the</strong> host files and<br />

external resources [5]. BOINC has identified two different<br />

sandbox environments. Account-based sandbox<strong>in</strong>g uses<br />

<strong>the</strong> OS capabilities of add<strong>in</strong>g and assign<strong>in</strong>g different user<br />

account levels [3]. The idea is to create a user account with<br />

no special privileges and <strong>the</strong>n run <strong>the</strong> BOINC application<br />

with<strong>in</strong> this account. Any rout<strong>in</strong>e that tries to access system<br />

<strong>in</strong>formation or file will not be allowed to.<br />

The second sandbox<strong>in</strong>g technique uses virtual mach<strong>in</strong>es<br />

completely encapsulat<strong>in</strong>g <strong>the</strong> applications runn<strong>in</strong>g with<strong>in</strong><br />

[6]. Applications runn<strong>in</strong>g on <strong>the</strong> virtual mach<strong>in</strong>es are<br />

isolated from rout<strong>in</strong>es, resources and host files. Virtual<br />

mach<strong>in</strong>es are <strong>the</strong> best example where we can see <strong>the</strong> work<br />

of sandbox environments. In security test<strong>in</strong>g areas, virtual<br />

mach<strong>in</strong>es play <strong>the</strong> role of host computers to run, test and<br />

study malicious applications without caus<strong>in</strong>g any harm to<br />

<strong>the</strong> physical computer.<br />

BOINC offers a tool to develop projects on virtual<br />

mach<strong>in</strong>es called vboxwrapper [7]. This tool allows <strong>the</strong><br />

developers to mount projects on virtual mach<strong>in</strong>e<br />

environments <strong>in</strong> a simpler manner, lett<strong>in</strong>g <strong>the</strong>m take<br />

advantage of <strong>the</strong> benefits <strong>in</strong> virtual mach<strong>in</strong>es.<br />

Many of <strong>the</strong> security threats identified by BOINC can<br />

be conta<strong>in</strong>ed us<strong>in</strong>g a virtual mach<strong>in</strong>e-based sandbox work<br />

model. Virtual Mach<strong>in</strong>es allow <strong>the</strong> project developers to<br />

work completely <strong>in</strong>dependent of <strong>the</strong> host system. This<br />

takes care of <strong>the</strong> compatibility issue between a project and<br />

IJCTA | MAY-JUNE 2012<br />

Available onl<strong>in</strong>e@www.ijcta.com<br />

945


Paulo Picota Cano et al ,Int.J.Computer Technology & Applications,Vol 3 (3), 944-948<br />

ISSN:2229-6093<br />

different host operat<strong>in</strong>g systems (Mac, L<strong>in</strong>ux, W<strong>in</strong>dows).<br />

These isolat<strong>in</strong>g capabilities also prevents malicious users<br />

from abus<strong>in</strong>g and attack<strong>in</strong>g <strong>the</strong> projects files [8]. Ano<strong>the</strong>r<br />

great advantage of <strong>the</strong> isolat<strong>in</strong>g capabilities of virtual<br />

mach<strong>in</strong>es is aga<strong>in</strong>st attacks such as <strong>in</strong>formation <strong>the</strong>ft,<br />

malicious code distribution and server overload.<br />

BOINC provides examples of ready-to-use virtual<br />

mach<strong>in</strong>es based on vboxwrapper and ready for <strong>the</strong><br />

developers to shape <strong>the</strong>m accord<strong>in</strong>g to <strong>the</strong>ir projects. The<br />

problem at this po<strong>in</strong>t is that <strong>the</strong> vboxwrapper is not<br />

compatible with any o<strong>the</strong>r processor architecture but Intel<br />

[7]<br />

In volunteer comput<strong>in</strong>g environments is very important<br />

to be able to determ<strong>in</strong>e <strong>the</strong> availability of <strong>the</strong> volunteer host<br />

<strong>in</strong> order to have some understand<strong>in</strong>g on how much will a<br />

task take to be f<strong>in</strong>ished. This situation can be solved with<br />

virtual mach<strong>in</strong>e sandbox<strong>in</strong>g [5]. The virtual mach<strong>in</strong>es have<br />

different methods to keep record of status and to pause <strong>the</strong><br />

task, so it can be retaken without any work lost.<br />

Figure 1 : BOINC Wrapper tool to communicate<br />

<strong>the</strong> applications with <strong>the</strong> client [11].<br />

There are some libraries that can be adapted to connect<br />

<strong>the</strong> BOINC middleware with virtual mach<strong>in</strong>es [9].<br />

Libbo<strong>in</strong>exec is a library that allows you to monitor several<br />

virtual mach<strong>in</strong>es.<br />

In [10] it is presented an adaption to <strong>the</strong> library<br />

alongside with some modifications to <strong>the</strong> BOINC<br />

wrapper’s virtual mach<strong>in</strong>e.<br />

As shown <strong>in</strong> fig 1, Wrapper is a BOINC tool that allows<br />

communication between <strong>the</strong> BOINC client and one or more<br />

applications that are <strong>in</strong>terpreted as a sub process <strong>in</strong><br />

sequence [11]. The method presented <strong>in</strong> [10] represents a<br />

valuable step towards <strong>the</strong> implementation of virtual<br />

mach<strong>in</strong>es for sandbox environments. It is focused on<br />

implement<strong>in</strong>g libbo<strong>in</strong>exec and virtual mach<strong>in</strong>es on BOINC<br />

work<strong>in</strong>g environments. In [5] it is presented an architecture<br />

model scalable to any grid project implement<strong>in</strong>g virtual<br />

mach<strong>in</strong>es for sandbox<strong>in</strong>g. The po<strong>in</strong>t is to create an<br />

application that could launch a virtual mach<strong>in</strong>e and support<br />

<strong>the</strong> architecture on figure 2:<br />

Figure 2: Virtual Mach<strong>in</strong>e Model Architecture<br />

[5].<br />

1. The Virtual Mach<strong>in</strong>e Application: hides<br />

<strong>the</strong> under runn<strong>in</strong>g architecture and manages <strong>the</strong><br />

different virtual mach<strong>in</strong>es and <strong>in</strong>teract<strong>in</strong>g with <strong>the</strong><br />

different <strong>in</strong>stances.<br />

2. The Backend: Saves <strong>the</strong> metadata of each<br />

virtual mach<strong>in</strong>e <strong>in</strong>stance allow<strong>in</strong>g <strong>the</strong> sandbox to open<br />

and close at any given time.<br />

3. The Base Image: Is <strong>the</strong> base to all <strong>the</strong><br />

virtual mach<strong>in</strong>e <strong>in</strong>stances. Each <strong>in</strong>stance is created<br />

from this base image conta<strong>in</strong><strong>in</strong>g all <strong>the</strong> necessary<br />

<strong>in</strong>formation to run <strong>the</strong> project.<br />

4. Instance Images: Each <strong>in</strong>stance must<br />

store its own image from <strong>the</strong> base image without<br />

corrupt<strong>in</strong>g <strong>the</strong> orig<strong>in</strong>al.<br />

5. Communication Daemon: Handles <strong>the</strong><br />

communications between <strong>the</strong> <strong>in</strong>stances and <strong>the</strong><br />

work<strong>in</strong>g hosts.<br />

6. Execution environment: Is where all<br />

applications run and it is stored with<strong>in</strong> each virtual<br />

mach<strong>in</strong>e.<br />

Proposed methods such as <strong>the</strong> M<strong>in</strong>imum <strong>in</strong>trusion grids<br />

seek <strong>the</strong> means to mix grid architecture and virtual<br />

mach<strong>in</strong>es. This work falls under <strong>the</strong> virtual mach<strong>in</strong>e<br />

sandbox model and help developers to improve security<br />

services and prevent possible threats.<br />

IJCTA | MAY-JUNE 2012<br />

Available onl<strong>in</strong>e@www.ijcta.com<br />

946


Paulo Picota Cano et al ,Int.J.Computer Technology & Applications,Vol 3 (3), 944-948<br />

ISSN:2229-6093<br />

4. M<strong>in</strong>imum Intrusion grids<br />

The concept for M<strong>in</strong>imum <strong>in</strong>trusion Grids (MiG) is<br />

presented <strong>in</strong> [8]. MiG is a technique <strong>in</strong>dependent to any<br />

previous grid implemented system. The ma<strong>in</strong> idea is to<br />

build a grid <strong>in</strong>frastructure that takes as m<strong>in</strong>imum<br />

requirements as possible from <strong>the</strong> host computers.<br />

The MiG implements virtualization techniques <strong>in</strong> a way<br />

that users will only need to have an X.509 certificate and<br />

support HTTP, HTTPS or SSH connection. MiG virtual<br />

mach<strong>in</strong>es conta<strong>in</strong> a ttyl<strong>in</strong>ux image as operat<strong>in</strong>g system<br />

allow<strong>in</strong>g very low load<strong>in</strong>g times [8]. The MiG us<strong>in</strong>g virtual<br />

mach<strong>in</strong>es and follow<strong>in</strong>g a sandbox<strong>in</strong>g model provides a<br />

security advantage that makes it a multiplatform solution.<br />

MiG also <strong>in</strong>cludes some improvements to <strong>the</strong> sandbox<br />

model. MiGs have 2 components: file remote access, uses<br />

identification techniques to access to resources libraries<br />

and task schedul<strong>in</strong>g sett<strong>in</strong>g a time limit for some task to be<br />

f<strong>in</strong>ished. If <strong>the</strong> task f<strong>in</strong>ish<strong>in</strong>g time is exceeded, said task<br />

will be given to a different host.<br />

5. Virtual mach<strong>in</strong>e based security<br />

framework (VMF)<br />

Code sign<strong>in</strong>g and <strong>the</strong> implementation of validat<strong>in</strong>g and<br />

assimilat<strong>in</strong>g result modules are some of <strong>the</strong> requirements<br />

that BOINC requests from <strong>the</strong> projects developers. In<br />

many cases, <strong>the</strong> tools and implementation of security<br />

measures are not very well understood by <strong>the</strong> project<br />

developers, thus mak<strong>in</strong>g <strong>the</strong> deployment of said security<br />

measures very difficult to apply [12].<br />

In figure 3, we propose a shell to develop a framework<br />

focused towards virtual mach<strong>in</strong>e sandbox<strong>in</strong>g environments<br />

and <strong>in</strong>clud<strong>in</strong>g <strong>the</strong> basic security requirements for any<br />

BOINC project.<br />

The proposed framework <strong>in</strong>cludes 2 ma<strong>in</strong> modules with<br />

a sub module aimed to attend <strong>the</strong> security issues and a<br />

result handler module as follows:<br />

1. Project Application Module: This module<br />

<strong>in</strong>cludes <strong>the</strong> BOINC framework to create and<br />

<strong>in</strong>stall <strong>the</strong> projects. To this exist<strong>in</strong>g framework we<br />

proposed add<strong>in</strong>g two new dist<strong>in</strong>ctive submodules:<br />

security and result handl<strong>in</strong>g.<br />

2. Result Handl<strong>in</strong>g Sub-module: This submodule<br />

<strong>in</strong>cludes <strong>the</strong> BOINC result handl<strong>in</strong>g<br />

requirements. The ma<strong>in</strong> idea is to organize <strong>the</strong><br />

result handl<strong>in</strong>g requirements <strong>in</strong>to one standard<br />

structural block <strong>in</strong> a way that developers could<br />

apply result handl<strong>in</strong>g accord<strong>in</strong>g to BOINC<br />

requirements [4].<br />

3. <strong>Security</strong> Sub-module: This sub-module<br />

<strong>in</strong>cludes <strong>the</strong> necessary tools to fulfill BOINC<br />

security requirements [3]. This module will<br />

present, to <strong>the</strong> project developers, <strong>the</strong> set of tools<br />

<strong>in</strong> a structured and organized way, improv<strong>in</strong>g <strong>the</strong><br />

learn<strong>in</strong>g and deploy<strong>in</strong>g process of this security<br />

measures. The advantage on implement<strong>in</strong>g this<br />

sub-module, is to make <strong>the</strong> deployment of security<br />

measures more accessible to <strong>the</strong> project<br />

developers on computer volunteer environments<br />

[12].<br />

4. Virtual Mach<strong>in</strong>e Module: This module<br />

comb<strong>in</strong>es <strong>the</strong> development platform of BOINC<br />

with <strong>the</strong> implementation of virtual mach<strong>in</strong>e<br />

sandbox<strong>in</strong>g. We propose to apply <strong>the</strong> architecture<br />

describe <strong>in</strong> section III, <strong>in</strong> a way that <strong>the</strong> virtual<br />

mach<strong>in</strong>e development would be modular [5].<br />

Figure 3: Framework Shell for <strong>the</strong> development of BOINC projects focused<br />

on virtual mach<strong>in</strong>e sandbox based security.<br />

IJCTA | MAY-JUNE 2012<br />

Available onl<strong>in</strong>e@www.ijcta.com<br />

947


Paulo Picota Cano et al ,Int.J.Computer Technology & Applications,Vol 3 (3), 944-948<br />

ISSN:2229-6093<br />

6. Conclusions and fur<strong>the</strong>r work<br />

From <strong>the</strong> work we have presented <strong>in</strong> this paper, <strong>the</strong> next<br />

step will be to make a statistic study of <strong>the</strong> implementation<br />

of <strong>the</strong> different security options with<strong>in</strong> <strong>the</strong> BOINC<br />

environment presented is section II.<br />

We have presented a robust and scalable platform such<br />

as BOINC and its many security options which might turn<br />

complex and difficult to implement. This complexity<br />

represents <strong>the</strong> ma<strong>in</strong> disadvantage <strong>in</strong> develop<strong>in</strong>g stronger<br />

projects <strong>in</strong> security measures [13].<br />

The poor understand<strong>in</strong>g of <strong>the</strong> developers regard<strong>in</strong>g <strong>the</strong><br />

implementation of security measures due <strong>the</strong> complexity of<br />

<strong>the</strong> implementation is <strong>the</strong> greatest obstacle <strong>in</strong> implement<strong>in</strong>g<br />

solutions and prevent<strong>in</strong>g security threats [12]. The solution<br />

is to focus our work <strong>in</strong> develop<strong>in</strong>g friendly environments<br />

and more friendly and organized techniques <strong>in</strong> order to<br />

make it more accessible to <strong>the</strong> projects developers to<br />

implement security measures with<strong>in</strong> distributed comput<strong>in</strong>g<br />

environments [12].<br />

The implementation of sandbox<strong>in</strong>g techniques and<br />

modular frameworks, such as <strong>the</strong> one on section V,<br />

toge<strong>the</strong>r with organized tools lower<strong>in</strong>g <strong>the</strong> complexity of<br />

deployment [12, 13] is <strong>the</strong> key solution to all security<br />

issues presented <strong>in</strong> this paper and allows to have a work<strong>in</strong>g<br />

model scalable to any distributed computational<br />

environment.<br />

References:<br />

[1] D. Anderson, "Public Comput<strong>in</strong>g: Reconnect<strong>in</strong>g People<br />

to Science," Conference on Shared Knowledge and <strong>the</strong> Web,<br />

2004.<br />

[2] BOINC. (2011). <strong>Security</strong> issues <strong>in</strong> volunteer comput<strong>in</strong>g.<br />

Available: http://bo<strong>in</strong>c.berkeley.edu/trac/wiki/<strong>Security</strong>Issues<br />

[3] BOINC. (2011). BOINC <strong>Security</strong>. Available:<br />

http://bo<strong>in</strong>c.berkeley.edu/wiki/BOINC_<strong>Security</strong><br />

[4] BOINC. (2011). Validation and replication<br />

[11] BOINC. (2011). The BOINC Wrapper Available:<br />

http://bo<strong>in</strong>c.berkeley.edu/trac/wiki/WrapperApp<br />

[12] B.Beckles, "A user-friendly approach to computational<br />

grid security ".<br />

[13] J. Baldassari, "Design and Evaluation of a Public<br />

Resource Comput<strong>in</strong>g Framework," Master of Science <strong>in</strong><br />

Computer Science, WORCESTER POLYTECHNIC INSTITUTE<br />

2006.<br />

Available:<br />

http://bo<strong>in</strong>c.berkeley.edu/trac/wiki/ValidationSummary<br />

[5] A. C. Marosi, P. Kacsuk, G. Fedak, and O. Lodygensky,<br />

"Sandbox<strong>in</strong>g for Desktop Grids Us<strong>in</strong>g Virtualization," pp. 559-<br />

566, 2010.<br />

[6] BOINC. (2010). Client security and sandbox<strong>in</strong>g.<br />

Available: http://bo<strong>in</strong>c.berkeley.edu/trac/wiki/SandboxUser<br />

[7] BOINC. (2011). Runn<strong>in</strong>g apps <strong>in</strong> VirtualBox virtual<br />

mach<strong>in</strong>es.<br />

Available:<br />

http://bo<strong>in</strong>c.berkeley.edu/trac/wiki/VboxApps<br />

[8] R. Andersen and B. V<strong>in</strong>ter, "Harvest<strong>in</strong>g Idle W<strong>in</strong>dows<br />

CPU Cycles for Grid comput<strong>in</strong>g."<br />

[9] D. Anderson, "BOINC A System for PublicResource<br />

Comput<strong>in</strong>g and Storage.pdf," IEEE/ACM International Workshop<br />

on Grid Comput<strong>in</strong>g, 2010.<br />

[10] F. A. Diogo Ferreira and P. Dom<strong>in</strong>gues, "Libbo<strong>in</strong>cexec:<br />

A generic virtualization approach for <strong>the</strong> BOINC middleware."<br />

IJCTA | MAY-JUNE 2012<br />

Available onl<strong>in</strong>e@www.ijcta.com<br />

948

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!