encrypted root filesystem

Gregory Davis gregdavis at ieee.org
Tue Feb 24 06:44:20 PST 2004


Ryan.Oliver at pha.com.au wrote:

> 
> 
> 
> 
> 
> I agree with encrypted filesystems, but honestly encrypting the root
> filesystem is horribly unwieldly.
> 
> Data should be encrypted, it isn't necessary to encrypt standard
> system binaries, libraries et al.
> 
> In fact you could argue that (as appears to have been argued already)
> by encrypting these known files you are supplying a crib if you are
> using a known distro of a known patch level.
> (for us it would be a hell of a lot harder due to everyone compiling
> from scratch)
> 
> The speed tradeoff of an encrypted root is *significant* .
> 
> Encryption is best placed where it is needed, say home dirs,
> protected system areas for admin/devel tools you don't want lying
> around (c-compilers, linkers et al + system include dirs), data
> partitions (even database partitions if you can handle the IO slowdown, if
> not application level encryption would be preferred).
> 
> This saves a hell of a lot of IO overhead, while protecting your
> sensitive material. Best of both worlds.
> 
> [R]

Furthermore, the encryption should be done in hardware.  We now have AES as
a standard, so put it on a chip and in harddisks.  Make it part of ATA. 
This way any blocks on disk you want to encrypt, get encrypted faster,
rather than purely as a kernel service.  The harddisk could then encrypt
its internal (and kernel transparent) buffers.  If people are really
paranoid about the Fibbies getting their drives, then part of the paydirt
is in the motherboard and disk buffers that don't get flushed.  Or "free"
space, the list goes on.  I long for the day when I insert a smartcard into
a slot on the computer and all my data are unbeatably encrypted for their
entire lifetime, and it all happens on the fly, and transparent to the
kernel.

Greg



More information about the hlfs-dev mailing list