lkml.org 
[lkml]   [1996]   [Dec]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Encrypted Filesystems (was: signing fs's)
Date
Gregory Maxwell wrote:
>
> Hmm.. Everyone was yakking about boot time passwords so that someone
> couldn't reboot with an alternate kernel or steal the computer.. How
> about this: The computer contains a simple card with cmos like memory
> (and power source).. It contains the magic key... It's attached to a
> microswitch on the case... If the case is opened then it 'forgets' the
> password.. Also the floppy would be disabled inside the case... This way
> if theres a power out or a system reboot in the middle of the night a
> sysadm doesn't need to be there to check it out...

This is not secure. An attacker can always open the case replace the hard
disk with an imposter containing a rougue kernel that boots, probes the cmos
for its value and writes it to the screen. The attacker can then use this
info to modify the filesystem as desired.

> As for signing stuff... A md5 is NOT a signature as would be useful for
> a security check... (it would have to be public-key encrypted to call it
> that).. What could be done is that every user could have a public-private
> key pair which could be loaded by the login process and used to sign
> blocks.. But I dont see much point as a sysadm could foul this and no one
> but a sysadm would be a threat to current methods...

You are thinking of PGP type digital signatures, where joe wants to be sure
terry signed something but terry does not want to give joe the power to sign
things on his behalf... public key digital signatures are generically slow
require long keys and for the purpose of maintaining a filesystem are more
cumbersome than the method I suggested (the kernel would needlessly be using
two keys).

The point of signing inodes with a cryptographically strong hash function
was suggested because it is likely to be quick enough to do in real time (in
comparison to harware I/O disk access). The security, as with all credible
algorithms, comes from the privacy of the key.

Finally, there are problems with the use of encryption. Certain countries
regulate its export (US) and others restrict its use (France, ...). Building
any encryption into the Kernel is not something that would contribute to the
free redistribution of Linux. Hash functions on the other hand are freely
redistributable/used. In suggesting the use of such a function I was trying
to suggest a simple method for providing some tamper-proofing for
filesystems used by the kernel - not trying to keep the data secret.

Best wishes

Andrew
--
Linux-PAM: http://parc.power.net/morgan/Linux-PAM/index.html
libpwdb: http://parc.power.net/morgan/libpwdb/index.html
[ For those that prefer FTP --- ftp://ftp.lalug.org/morgan ]

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