Messages in this thread | | | From | "Andrew G. Morgan" <> | Subject | Re: Encrypted Filesystems (was: signing fs's) | Date | Sun, 29 Dec 1996 14:27:04 -0800 (PST) |
| |
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 ]
| |