KB

As of 2006-01-09, the vision from KB is that metadata are stored in immutable form. New versions of metadata points to the old versions.

The archives containing past metadata (most probably WARC) are duplicated and checksummed. If a person wants to tamper with these data, it would require changes to all copies of the archive in question. This would require security breaches at KB and SB at around the same time.

Changing present metadata in an undetected way would require access to the metadata ingest mechanism at KB, as manually creating and storing a new archive in the system is an unrealistic task. A new ingest would leave the old versions of the metadata intact, thereby making it easy to inspection changes in case of suspecion of tampering.

SB

The vision from SB is that metadata are updated often and that snapshots of the metadata are stored regulary. New versions of metadata are stored in the same file as the old versions.

Snapshots are stored in a manner similar to KB and tampering with those would thus be very hard to do.

Changing present metadata in an undetected way could be done in at least two ways

  1. By using the metadata ingest mechanism. As with KB, this would leave past versions of metadata easily accessible and as such would be critical to integrity.
  2. By changing the metadatafiles on the disk. This is quite possible with the current candidate Fedora and would result in a critical breach in integrity.

It is possible to counteract #2, by making regular checks between a permanently stored immutable snapshot and a new snapshot. Any changes between the two snapshots is supposed to be documented in the audit trail. If not, then the object has been tampered with.

Such a check should be performed each time a snapshot is to be stored.

Ensuring integrity (last edited 2010-03-17 13:08:52 by localhost)