2002-07-07 20:39:24 +00:00
|
|
|
<body bgcolor=ffffff>
|
2002-04-30 22:22:54 +00:00
|
|
|
<h2>Security</h2>
|
|
|
|
|
|
|
|
|
|
<p>
|
2002-07-07 20:39:24 +00:00
|
|
|
Many types of attacks are possible in public-participation
|
|
|
|
|
distributed computing.
|
|
|
|
|
<ul>
|
|
|
|
|
<li> <b>Result falsification</b>.
|
|
|
|
|
Attackers return incorrect results.
|
|
|
|
|
<li> <b>Credit falsification</b>.
|
|
|
|
|
Attackers return results claiming more CPU time than was actually used.
|
|
|
|
|
<li> <b>Malicious executable distribution</b>.
|
|
|
|
|
Attackers break into a BOINC server and, by modifying
|
|
|
|
|
the database and files, attempt to distribute their own executable
|
|
|
|
|
(e.g. a virus program) disguised as a BOINC application.
|
|
|
|
|
<li> <b>Overrun of data server</b>.
|
|
|
|
|
Attackers repeatedly send large files to BOINC data servers,
|
|
|
|
|
filling up their disks and rendering them unusable.
|
|
|
|
|
<li> <b>Theft of participant account information by server attack</b>.
|
|
|
|
|
Attackers break into a BOINC server and steal email addresses
|
|
|
|
|
and other account information.
|
|
|
|
|
<li> <b>Theft of participant account information by network attack</b>.
|
|
|
|
|
Attackers exploit the BOINC network protocols to steal
|
|
|
|
|
account information.
|
|
|
|
|
<li> <b>Theft of project files</b>.
|
|
|
|
|
Attackers steal input and/or output files.
|
|
|
|
|
<li> <b>Intentional abuse of participant hosts by projects</b>.
|
|
|
|
|
A project intentionally releases an application that
|
|
|
|
|
abuses participant hosts, e.g. by stealing sensitive information
|
|
|
|
|
stored in files.
|
|
|
|
|
<li> <b>Accidental abuse of participant hosts by projects</b>.
|
|
|
|
|
A project releases an application that unintentionally
|
|
|
|
|
abuses particpant hosts, e.g. deleting files or causing crashes.
|
|
|
|
|
|
|
|
|
|
</ul>
|
|
|
|
|
BOINC provides mechanisms to reduce the likelihood of some of these attacks.
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
<b>Result falsification</b>
|
|
|
|
|
<p>
|
|
|
|
|
This can be probabilistically detected using
|
|
|
|
|
redundant computing and result verification:
|
|
|
|
|
if a majority of results agree
|
|
|
|
|
(according to an application-specific comparison)
|
|
|
|
|
then they are classified as correct.
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
<b>Credit falsification</b>
|
|
|
|
|
<p>
|
|
|
|
|
This can be probabilistically detected using
|
|
|
|
|
redundant computing and credit verification:
|
|
|
|
|
each participant is given the minimum credit from among
|
|
|
|
|
the correct results.
|
2002-04-30 22:22:54 +00:00
|
|
|
|
|
|
|
|
<p>
|
2002-07-07 20:39:24 +00:00
|
|
|
<b>Malicious executable distribution</b>
|
|
|
|
|
<p>
|
|
|
|
|
BOINC uses code signing to prevent this.
|
|
|
|
|
Each project has a key pair for code signing.
|
|
|
|
|
The private key should be kept on a network-isolated machine
|
|
|
|
|
used for generating digital signatures for executables.
|
|
|
|
|
The public key is distributed to, and stored on, clients.
|
|
|
|
|
All files associated with application versions are sent
|
|
|
|
|
with digital signatures using this key pair.
|
|
|
|
|
<p>
|
|
|
|
|
Even if attackers break into a project's BOINC servers,
|
|
|
|
|
they will not be able to cause clients to accept a false code file.
|
|
|
|
|
<p>
|
|
|
|
|
BOINC provides a mechanism by which projects can periodically
|
|
|
|
|
change their code-signing key pair.
|
|
|
|
|
The project generates a new key pair,
|
|
|
|
|
then (using the code-signing machine)
|
|
|
|
|
generates a signature for the new public key,
|
|
|
|
|
signed with the old private key.
|
|
|
|
|
The core client will accept a new key only if it's signed with the old key.
|
|
|
|
|
This mechanism is designed to prevent attackers from breaking into
|
|
|
|
|
a BOINC server and distributing a false key pair.
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
<b>Overrun of data server</b>
|
|
|
|
|
<p>
|
|
|
|
|
Each result file has an associated maximum size.
|
|
|
|
|
Each project has a <b>upload authentication key pair</b>.
|
|
|
|
|
The public key is stored on the project's data servers.
|
|
|
|
|
Result file descriptions are sent to clients with a digital signature,
|
|
|
|
|
which is forwarded to the data server when the file is uploaded.
|
|
|
|
|
The data server verifies the file description,
|
|
|
|
|
and ensures that the amount of data uploaded does not exceed the maximum size.
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
<b>Theft of participant account information by server attack</b>
|
|
|
|
|
<p>
|
|
|
|
|
Each project must address this using conventional security practices.
|
|
|
|
|
All server machines should be protected by a firewall,
|
|
|
|
|
and should have all unused network services disabled.
|
2002-04-30 22:22:54 +00:00
|
|
|
Access to these machines should be done only
|
|
|
|
|
with encrypted protocols like SSH.
|
|
|
|
|
The machines should be subjected to regular security audits.
|
2002-07-07 20:39:24 +00:00
|
|
|
<p>
|
|
|
|
|
Projects should be undertaken only the organizations
|
|
|
|
|
that have sufficient expertise and resources to secure their servers.
|
|
|
|
|
A successful attack could discredit all BOINC-based projects,
|
|
|
|
|
and public-participation computing in general.
|
2002-04-30 22:22:54 +00:00
|
|
|
|
|
|
|
|
<p>
|
2002-07-07 20:39:24 +00:00
|
|
|
<b>Theft of participant account information by network attack</b>
|
|
|
|
|
<p>
|
|
|
|
|
The
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
<b>Theft of project files</b>
|
|
|
|
|
<p>
|
|
|
|
|
The input and output files used by BOINC applications are not encrypted.
|
2002-04-30 22:22:54 +00:00
|
|
|
Applications can do this themselves, but it has little effect
|
|
|
|
|
since data resides in cleartext in memory,
|
|
|
|
|
where it is easy to access with a debugger.
|
|
|
|
|
|
|
|
|
|
<p>
|
2002-07-07 20:39:24 +00:00
|
|
|
<b>Intentional abuse of participant hosts by projects</b>
|
2002-04-30 22:22:54 +00:00
|
|
|
<p>
|
2002-07-07 20:39:24 +00:00
|
|
|
BOINC does nothing to prevent this
|
|
|
|
|
(e.g. there is no "sandboxing" of applications).
|
|
|
|
|
Participants must understand that when they join a BOINC project,
|
|
|
|
|
they are entrusting the security of their systems to that project.
|
2002-04-30 22:22:54 +00:00
|
|
|
|
|
|
|
|
<p>
|
2002-07-07 20:39:24 +00:00
|
|
|
<b>Accidental abuse of participant hosts by projects</b>
|
2002-04-30 22:22:54 +00:00
|
|
|
<p>
|
2002-07-07 20:39:24 +00:00
|
|
|
BOINC does nothing to prevent this.
|
|
|
|
|
The chances of it happening can be minimized by
|
|
|
|
|
pre-released application testing.
|
|
|
|
|
Projects should test their applications thoroughly on all platforms
|
|
|
|
|
and with all input data scenarios before
|
|
|
|
|
promoting them to production status.
|
