The only reason Kernel level encryption/signing would be needed
is in a high security/high threat environment. And if you are
running a system like that you had better have your own experts
and roll and test much of the code locally. I doubt that it is
possible to have a publicly distributed kernel that goes significantly
beyond C2 out of the box. (I have been doing some reading since I
posted this.) But it is nice to have the ability to create such a
system for those who need it.
On Wed, 8 Jan 1997 tytso@mit.edu wrote:
> OK,
> I've been keeping quite on this thread for a while, but there
> have been a number of wrong assertions which I want to correct:
>
> > Encryption addresses the proper concern. An encrypted file
> > cannot be modified without decrypting it first. Any attempt
> > to modify it in it's encrypted state is likely to render the
> > file useless rather than simply changing the data by making
> > it impossible to decrypt.
>
> Incorrect. Integrity and Data Confidentiality are different things,
> and it's a bad assumption that Data Confidentialty automatically
> implies that you have Integrity. Just to give a simple example,
> suppose your encryption algorithm is DES OFB. This provides good Data
> Confidentialiity (or as good as DES will give you), but if you know
> the plaintext, you can XOR away the known plaintext, and then XOR in
> new values. This is just a simple example of a scheme can provide
> data confidentialty, while not providing any protection against
> modification in the face of known plaintext.
>
> Cryptographers have long advised that Integrity and Data Confidentialty
> be considered separate services, provided by separate algorithms, and
> indeed using different cryptographic keys. (That way a break in the key
> providing data confidentiality doesn't compromise your data integrity.)
>
>
> More generally, I have to ask the question why are we trying to do
> cryptography at the filesystem level at all? What is your threat model?
> Who are you trying to protect your data against? What sort of resources
> is your adversary going to have?
>
> It is not at all clear to me that the filesystem is really the right
> place to be doing this sort of protection. Since the integrity
> protection and signing is taking place in the kernel (and the
> cryptographic keys have to present in the kernel at all times while it
> is running), this scheme doesn't protect you against someone who has
> managed to get superuser access. It only protects you against someone
> who has physical access to your disk while the kernel isn't running.
> However, is this a threat model which is most people will commonly see?
>
> - Ted
>
Daniel Taylor Digi International Tech Support