> - the IV for a disk sector is simply the sector number, so if
> an attacker can copy your hard drive without your knowledge,
> then you change something (e.g. update a database field) and
> the attacker reads the disk again, he can tell the exact
> location (in AES blocks) of the first change in the sector....
If attacker can copy your hard drive without your knowledge, he can
also install trojan kernel -- it is 'game over' next time you mount
that encrypted partition.
I don't think so, it's easy to see ways this could happen. Suppose
you have a file-backed loop_aes FS, and it's backed up periodically as
part of a regular system dump and the backup tapes are archived. Now
if the attacker gets hold of the series of backup tapes, he has a set
of snapshots of your FS that he can use that attack on. Or if the
underlying file system is log structured (sectors never get
overwritten unless the whole disk is full, and file operations can be
rolled back), simply getting the hard drive would get all those
snapshots, without needing the tapes.
An attacker who actually accesses the hardware also might choose not
to install any trojans because it increases the chance of detection.
Maybe I boot my laptop from a USB flash disk that I keep in my pocket,
and it validates checksums on the hard drive before going interactive.
Or maybe he wants to install a hardware bug (keystroke recorder), but
he has to assume I check for those. Installing something like that in
a laptop may not be so easy anyway.
Loop encryption is supposed to protect data _after_ laptop theft
or something like that where you won't see or use your laptop any more.
In that case, there's no need to mess with CBC mode or initialization
vectors. You could just use AES in counter mode over the whole
partition, or use RC4 keyed by a hash of the FS key and the sector
number. Even doing the hash RC4 key initialization on every sector,
it should still be much faster than AES, for reasonable sector sizes.
I really don't think any of those methods are safe though, even if
you're a device backed loopback FS. Suppose there's a modern IDE disk
drive underneath and it develops a soft error (i.e. correctable by
ECC) on some sector. The drive might very well remap that sector to a
spare sector completely invisibly to the OS or the user. Now if the
attacker gets two versions of the same sector, he can just xor them
together and get back the xor of the two plaintexts.
CBC mode as currently implemented in loop_aes is somewhat better than
that, but I think Colin's scheme is better still.
Your point about about IV computation is still true. If I remember
correctly, PPDD does pre-encryption whitening, so attacker can only
detect which 512 byte sector was changed.
What's PPDD? I remember looking at the loop_aes code and didn't
notice any whitening (just plain CBC) but may have missed something.
True. If I could start from scratch without backward compatibility
worries, I would implement IV computing differently.
There's already interchangeable block ciphers; might as well have an
alternative chaining mode.
Encrypting two filesystems with same seed (salt) is admin
screwup. Just don't do that.
OK. Docs should emphasize that.
> Using separate salts helps with this prob but is inconvenient if the
> FS's are removable (such as CD-roms). Maybe a mount option could
> be added to use the cd-rom volume ID as a salt,
Now, how is the code able to read cd-rom volume ID from encrypted
cd-rom? It is chicken-and-egg problem.
Oh oops, I thought the volume id was outside the iso9660 FS, but it's not.
Darn.
Ugly workaround for this is to add 4096 byte offset to encryption and use
sha512 of first 4096 bytes as the seed. Something like this:
Yeah, I guess that works, though it uses up a sector. (Why 4096 bytes?
I thought cd-rom had 2048 byte sectors). I'm trying to think if skipping
the sector has any other bad consequences--I guess not. Otherwise there
are some further workarounds possible, since the beginning of an ISO9660
file system appears to be arbitrary (mkisofs puts its own copyright notice
there) so a random string could be put there instead.
Thanks.
Paul
-
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
