Re: loop_aes comments

[Jari Ruusu <jari.ruusu@pp.inet.fi>]

Paul Rubin wrote:
>     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.

Yes, that leaks some information about which cipher block was the first one
changed inside a 512 byte sector. But being able to detect which 512 byte
sector was modified, is also information leak. Just less so.

> 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.

If filesystem blocks are written to different sectors, they are encrypted
with different IV. Your point was about detecting changes to same sector.

> 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.

Yes, USB or CDROM boot would be more secure.

>     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.

IV + CBC reduce chances of identical cipherblocks. And identical
cipherblocks leak information.

> 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.

xor trick works with CTR mode, but not with CBC mode.

> CBC mode as currently implemented in loop_aes is somewhat better than
> that, but I think Colin's scheme is better still.

I never said Colin's wasn't better. I agree 100% with you.

>     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.

PPDD == Allan Latham's PPDD

http://linux01.gwdg.de/~alatham/ppdd.html

>     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.

I have been considering that for more than a year now. Tricky part is doing
it without creating (in)compatibility mess. Just look at SuSE twofish /
kerneli.org twofish and their incompatible IV computing mess and you
understand what I mean.

>     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.

2048 sould work ok for cdrom. 4096 was just 'always safe' choice.

> 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.

Another chicken-and-egg problem. You can't encrypt before you know the seed.
And if seed is sha512sum of some ciphertext....

Regards,
Jari Ruusu <jari.ruusu@pp.inet.fi>

-
Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/