🚀 go-pugleaf

Greg Limes (limes@ouroborous.eng.sun.com) wrote:
> owens@acsu.buffalo.edu (Bill Owens) writes:
>|   Without adding the overhead of a digital signature for each file which
>|   tripwire is keeping track of, could the program perhaps be set up to
>|   check a cryptographic signature on the entire database?  If the key
>|   used to make the signature were kept secure, presumably by encrypting
>|   it, then I think this setup would be equally secure.
>I think this is insufficient.
>Let's say you protected a key program with such a signature, and used
>a shell that would check such signatures before executing the program.
>I'm a baddie, with sufficient (but maybe temporary) privileges on your
>system that I can change the bits in the program (or maybe I'm a
>virus). I change what I want to change, subverting the program. Then I
>find some other bits that I don't care about, and twiddle them until
>the signature is right. If I can make that backward calculation either
>directly or by trial-and-error in a reasonable time, then your
>signature protection system is no protection.

Hopefully that attack is computationally infeasible for good message
digest functions, like MD5 and Snefru.  But with such privileges, and a
database on a writable filesystem, the intruder could simply modify the
database to reflect the new value, and then modify the database's
signature to agree. However, that's not what I was suggesting.  To
re-establish the context of my original comment; I was replying to
another article, and using the author's terminology (which I realize
now is potentially confusing):

Kevin McCurley (mccurley@cs.sandia.gov) wrote:
>I would like to comment that this use of the term "signature" should
>not be confused with the much stronger term of signature that is
>common in cryptology literature.

The 'digital signature' I was referring to was what Kevin brought up;
not just a message digest like MD5 but rather a message digest
encrypted through a public-key cryptographic system. Such signatures
are regarded as unforgeable, and if the checksum is a strong one, it
should be a guarantee of the authenticity of the file being signed.

Kevin went on to say that if a digital signature were used for every
file which tripwire was monitoring, then a read-only database would not
be necessary. I was proposing to modify this idea by using the usual
checksum routines (MD5, MD4, Snefru, etc.) to build the database, in
the name of speed, with the added step of creating a digital signature
for the *entire database*. Tripwire could then check that signature
using the public key of the signer (the software maintainer, probably)
and know that the database was good.

This allows a modification of the original setup; now, the database may
be kept on a rw filesystem, for ease of maintenance, and only the
secret key used for the signature need be protected. The key systems
I'm familiar with (PGP and RIPEM) encode the secret key with DES,
which, IMO, should be sufficient. The public key and the signing
program could be protected by tripwire, so they could also be on the rw
filesystem.  As a first cut, the signing/checking process could be
handled manually, rather than by tripwire; eventually, parts of the
RSAREF package could be used within tripwire to do the job.

Now that I've hopefully made myself clear, does this seem reasonable?
The main question I have is whether MD5 is usable for this purpose;
that is, whether an MD5 digest of an MD5 digest of a file guarantees
the original file's integrity. Although I don't see any reason why not,
my mathematical knowledge is nowhere near that level ;)

Bill.
Bill Owens                                              owens@acsu.buffalo.edu
104E Computing Center                             uunet!acsu.buffalo.edu!owens
Buffalo, NY 12460                                                 716/645-3511