Databases Reference
In-Depth Information
R
. Mallory subsequently gains access to the storage server and looks for mag-
netic traces of
R
. He also looks in the current copies of indexes and other
metadata and supporting data structures, to try to glean information about
R
. For many applications, trustworthy record retention needs to prevent Mal-
lory from gaining any information about
R
.
4 Storage Architectures
As explained in detail in other chapters of this topic, conventional file/storage
system access control mechanisms and data outsourcing techniques are in-
tended to ensure that records and their metadata are only modified by legit-
imate applications. Under the outsourcing threat model, insiders are trusted
but the storage server is not. The correctness of outsourced query answers can
be guaranteed by the data owner by attaching appropriate signatures to the
data that can be verified by the querier. These signature-based approaches
only detect whether a record has been tampered with; they do not prevent
tampering. The techniques for outsourcing and traditional access control are
powerless against an adversary with superuser powers who can obtain any
secret key and control the behavior of applications. Data owner Alice could
alter the contents of her record
R
and re-sign it after it has already been
committed to the storage server, or superuser Mallory could obtain access to
Alice's private key and alter and re-sign
R
himself. In many applications, a
key requirement for trustworthy retention of records is to
prevent
deletion and
modification of the records. To thwart these attacks, we need a new kind of
storage architecture [14]:
•
Based on the computer security principle of minimizing the trusted com-
puting base,
the component for enforcing the storage security
properties should be as small as possible
, both to reduce the proba-
bility that something could go wrong or be compromised, and to increase
our ability to verify the correctness of the component. This means that we
cannot rely on having a trusted database management system running on
the storage server, or even a trusted indexing package.
•
The
cost of any effective attack against the component must be
high, and its results must be conspicuous
. For example, perhaps a
simple auditing routine is guaranteed to be able to detect the aftereffects of
the attack; or else many or all records insertions will fail after the attack. A
number of design principles follow from this requirement; for example, the
component should have a
simple and well-defined interface
, to robustly
restrict trac into the component to legitimate requests only. Further,
the component must
mediate all requests
; in other words, the overwrite
protection cannot be circumvented by, for example, directly accessing the
rewritable disk.
•
The resulting system must provide
end-to-end security guarantees
,
not just guarantees for individual components.
