lkml.org 
[lkml]   [1997]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: signing a filesystem
OK, caught me out on that. You are correct, and the concerns
can truly be addressed by the user file system module. Just
use modules for integrity and encryption instead of compression.

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


\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.091 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site