Trusted Data Management for Grid-Based Medical Applications - Cloud, Grid and High Performance Computing: Emerging Applications - page 216

thentication be trusted. Job integrity verification
can be implemented securely if all initial content
of the job is signed by its owner, thus creating an
unforgeable binding between all components of
a job, including its proxy certificate.
A secure job container could be created before
submitting the job, which is signed using the job
owner's private key - see a similar idea in (van
't Noordende, Brazier & Tanenbaum, 2004). A
job container has a well-defined structure, which
makes it straightforward for the middleware to
find the components of the job that are relevant
for integrity verification. Alternative implementa-
tions are conceivable, e.g., using signed Virtual
Machine images (Travostino et al., 2006).

are concerned with data transfer aspects (e.g.,
gridFTP) are extended with functionality to report
a signed HPL to their peer processes at connection
time. Based on whether peers trust each other to
provide correct information, and on the informa-
tion in their HPLs, both parties decide whether to
proceed with the transaction (e.g., data transfer),
which takes place over a mutually authenticated
secure channel. Agreement should be reached on
the properties in the data item's RHPL before any
data is shipped.
For non-repudiation, both parties must co-sign
a microcontract once agreement is reached. Non-
repudiation means that none of the parties can
deny that they agreed on the contract's content.
To allow for auditing the exact operations on a
particular data item, the microcontract has to be
bound to each individual transaction, by including
e.g., a hash over the data and the operation in the
microcontract.

Host Property Lists

For risk assessment and policy enforcement, hosts
should announce security relevant properties of
their operating system, its configuration, and the
used middleware, including properties regarding
job integrity verification, in their Host Property
List (HPL). The host administrator has the respon-
sibility to fill in the HPL correctly. As a concrete
example, the HPL could report on whether the
operating system was configured to use encrypted
swap space, on whether the middleware is capable
of job integrity verification, and provides jobs
with a private file system that is removed after
the job exits.
HPLs allow for run-time assessment on wheth-
er a host adheres to the requirements for secure
data handling as imposed by a data owner. This
assessment takes place at the time that a connec-
tion is made to the TSRB. Because HPL matching
takes place at connection time, no external trusted
repository of HPLs is required for security.

Trusted Storage Resource Broker

The TSRB is the key component for managing all
privacy sensitive data in our framework. The TSRB
is the central reference monitor and access point
for data stored through this TSRB. In particular,
the TSRB enforces the access control policies
outlined in this paper. For clarity of exposition, we
assume that the TSRB is a non-distributed service
running in a single domain. The TSRB (and by
implication, domain) is determined as trusted by
a data owner prior to storing data on it.
Although we refer to the TSRB as a resource
broker here, the TSRB is effectively an abstrac-
tion for a secure storage system. In case where the
TSRB uses distributed facilities (e.g., untrusted
storage elements managed by different domains),
the TSRB can implement broker functionality.
In this case, the TSRB should make sure that it
stores only encrypted data on untrusted storage,
using cryptographic filenames. Example storage
systems that are implemented as a broker for

Microcontracts

Microcontracts state the obligations that the site
holds with regard to a transaction. Our framework
requires that all Grid middleware components that