lkml.org 
[lkml]   [1997]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: signing a filesystem
From
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

\
 
 \ /
  Last update: 2005-03-22 13:38    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site