Subject: Re: Volunteers to test some kernel code...
To: Brett Lymn <firstname.lastname@example.org>
From: Simon J. Gerraty <email@example.com>
Date: 06/15/1999 23:47:16
>According to Michael Graff:
>>Without a cool public key system, where NetBSD Foundation, Inc
>>binaries could be signed and distributed (and presumably trusted) I
>>don't know why, other than for experimentation, this would be used...
>Maybe I am being a bit simplistic here but isn't the MD5 signatures
>available from the ftp server good enough to assure some level of
>trust that the distribution has not been tampered with? (yes,
A digital signature is much more useful than an MD5 list.
A signature typically contains a hash (MD5 or SHA1) of the data being
signed, plus the same thing encrypted with the signers private key (RSA
or DSS?). Anyone with access to the signers public key (eg an x509
cert signed by Veri$ign or Twaite(sp?) etc so they can verify the public
key belongs to TNF) can decrypt the encrypted hash, check that it
matches the unencrypted one - signature is valid, and the hash independently
computed by the verifyer - the data has not been tampered with.
As someone else mentioned, putting the signature into the binary itself
is even better. Now you can download a binary from ftp.netbsd.org and
provided it has not been tampered with it will run - in the presense of
your signature checking kernel.
You could combine that with my earlier suggestion - if the signature verifies
ok, you store its fingerprint in the inode (which was cleared when you saved
the file of course), then noexec-unsigned* need only check for the presense
of the fingerprint.
Or s/fingerprint/execute permissions/ :-)
>What I was looking to do was to plug some of the standard script
>kiddie tricks such as loading trojan horses (can be fixed with
>immutable) and running network sniffers. I believed that having a
>validation of the TCB via a cryptographically strong method (I believe
>md5 is one) was a nicety - saves running tripwire or the like over the
>binaries since they are handled automatically.
But if your solution involves immutable files anyway, then tripwire
is probably good enough. I'm not (yet) convinced that computing
hashes of files at exec(2) time buys anything. I'm no saying that
signed binaries have no value, just that I think you can optimize
away the dynamic hashing.
Given that I build firewalls on a regular basis I am interested in
impoving the assurance levels, but cpu always runs out so its worth
saving it where possible.