[Esip-preserve] On Earth Science Data File Uniqueness

[Bruce Barkstrom]

Good, we're starting to gather threat scenarios that will be useful
in developing (perhaps a long time in the future) recommended
approaches to reduce the risks associated with particular attack
strategies.

Also, given the fact that cryptographic digests and such seem to
have a finite lifetime before they're broken, it may be useful to think
a bit about really long-term preservation.  If we move in this direction,
we'll need to begin to quantify the probability (per unit time) that there
will be a successful attack and then to quantify the probable loss.

Along this line, one strategy for dealing with these kinds of attacks
is to place some data in a dark archive, from which a "well-preserved"
copy is drawn out occasionally and used to audit the state of test
files.  Another alternative is to make sure the archive is distributed
and then compare which ones have reliable copies of the original.
The problem for us will be a bit more complicated because of the
"equivalence class" business, although we might make that work
for us because it means that you could maintain the "social trust"
of the LOCKSSS comparison strategy but now the algorithm would
be public and independently replicated.

This may turn out to be a pretty interesting problem.

Bruce B.

On Wed, Feb 16, 2011 at 10:24 AM, Curt Tilmes <Curt.Tilmes at nasa.gov> wrote:

> On 02/16/11 09:21, Bruce Barkstrom wrote:
> > Actually, I've had at least one instance that I would classify as
> > "malicious".
> > In ERBE, we were honest about recording instances in which we couldn't
> > observe "clear skies".  Other researchers took our data, modified the
> values
> > in those cases and then "published" their revisions as "ERBE" data.
>  While
> > the republishers were not the security community's "black hats", the
> effect
> > was the same.
>
> Our typical scenario for publishing data would be the archive making a
> data granule:
>
>
> ftp://aurapar2u.ecs.nasa.gov/data/s4pa///Aura_OMI_Level2/OMTO3.003//2011/047/OMI-Aura_L2-OMTO3_2011m0216t0444-o35051_v003-2011m0216t125137.he5
>
> and it's metadata:
>
>
> ftp://aurapar2u.ecs.nasa.gov/data/s4pa///Aura_OMI_Level2/OMTO3.003//2011/047/OMI-Aura_L2-OMTO3_2011m0216t0444-o35051_v003-2011m0216t125137.he5.xml
>
> which includes a field for size in bytes: 38892592
> and CRC32 checksum: 148881205
>
> After downloading that granule from the first link, and the metadata
> in the second link, I re-calculate the checksum and verify that it
> matches.  If it does, I have increased my confidence that the content
> the archive thinks it sent to me and the content I think I received
> are the same.
>
> With a simple checksum like CRC32, it is trivial for a malicious agent
> at the DISC to replace the content on the server side with some
> content that has the same CRC32 checksum.
>
> With a 'broken' algorithm like MD5 or SHA-1, that malicious agent
> might be able to use considerable work and do the same.  The attack
> methods are severely constrained such that it may be difficult to come
> up with valid data at all, but it is conceivable.
>
> With an as-yet un-broken algorithm like SHA-256 or SHA-512, it is
> computationally infeasible for that malicious agent to do the same.
>
> Of course, in this scenario, that malicious agent could easy replace
> both the content and the metadata with a new digital signature.
>
> Others who had downloaded the correct metadata would have the old,
> correct one, so conceivably you could catch the problem and
> investigate?  If the malicious party replaced the data before it was
> sent out, you're out of luck.  That malicious party could probably
> just mess with the algorithm to make bad data to begin with too..
>
> Curt
> _______________________________________________
> Esip-preserve mailing list
> Esip-preserve at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-preserve
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-preserve/attachments/20110216/aa29391f/attachment.html>