Databases Reference
In-Depth Information
•
Finally, in phase 3, the party in charge of migration moves the files to be
migrated, and also copies the signed log to the new server.
After migration, anyone can look up the public keys used by an organi-
zation's series of storage servers, and then use validation routines to check
whether the migration took place appropriately. For example, a trusted third-
party auditor can certify the migration immediately after its completion, at
approximately the same rate of speed as it took to generate the certificates
in phase 2. At any point after the migration, a user can also quickly check
whether a particular file was migrated appropriately.
A long-lived record may be migrated several times during its lifetime. If
we migrate all previous logs during each of the component migrations, then
the entire migration chain can be validated at any subsequent point. The
disadvantage of this approach—and a potential concern in even a single-hop
migration—is that a significant amount of information about deleted and/or
omitted files may be present in the log. For example, if a file has been omitted
during a previous migration, enough information must be present in the log
for a verifier to be sure that the omission was appropriate. To address this
problem, more complex schemes can be used to reduce the amount of migrated
information about deleted files, to the point where a deleted file can appear
in the log as just an opaque ID and expiration date.
Migration policies can be very complex. For example consider the policy
Delete all files containing the word
Martha
.
This deletion should preserve
confidentiality: a person reading files and logs on the destination server should
not learn anything other than the fact that the deleted file contained
Martha
.
One can handle this problem in an elegant manner if the storage server con-
tains a small amount of trusted hardware that can run downloaded query
code and sign the results, to testify that only a certain set of files contained
the word
Martha
[22]. Then this certificate can be included in the log file and
migrated to the new server along with the appropriate subset of files. Any-
one can verify that exactly the set of files listed in the query certificate was
omitted during the migration.
8 Trustworthy Deletion
Since the primary purpose of WORM devices is to prevent data deletion,
it is not surprising that cost-effective and trustworthy deletion of records is
dicult. WORM devices use physical security measures, such as repeatedly
overwriting the data blocks with certain patterns, to erase records from the
media. However, simple erasure is not enough for trustworthy deletion, as an
erased record can be recreated by reverse-engineering an index. Overall, no
index entry deletion scheme developed so far meets all the requirements for
trustworthy deletion.
For the deletion of document
d
to be
strongly secure
, the presence or ab-
sence of any word
w
in any reconstruction of
d
should not convey any in-
