Re: Re: [patch] cgd

["Roland C. Dowdeswell" <elric%imrryr.org@localhost>]

On Thu, Dec 02, 2010 at 04:49:51AM +0000, Taylor R Campbell wrote:
>

>    Date: Thu, 2 Dec 2010 03:39:10 +0000
>    From: "Roland C. Dowdeswell" <elric%imrryr.org@localhost>
> 
>    This brings up an interesting point which is that you are effectively
>    discussing that the ``protocol'' defined here is susceptible to a
>    replay attack.
> 
> Yes.  What I was getting at a little more generally is that the
> `protocol' is badly broken if an attacker can modify the disk.  In
> other words: throw it out and recover from backups.  I ought to have
> stated that outright, but instead I just said that cgd doesn't provide
> authenticity or integrity.

It is correct to state that CGD doesn't provide authenticity or
integrity because it doesn't.  There are problems beyond that, though,
which you are mentioning that are quite difficult to solve at the disk
layer.

We could, e.g. get around the problem that CBC mode has where you
can make predictable changes to the plaintext by implementing either
XTS or CMC modes.  These would make predictable modifications more
difficult but do nothing for rewinding either ciphertext blocks
(XTS) or entire sectors (CMC).

>                                       The best that you could do is
>    force the attacker to have to rewind the entire disk to a previous
>    state rather than simply rewinding sectors at a time or ciphertext
>    blocks at a time given the constraints of the problem.  Using an
>    HMAC can't completely solve this problem.
> 
> If you can force the attacker to rewind the entire disk, perhaps a
> timestamp and on the disk could do the trick, if the user can remember
> the last time he wrote to the disk.  However, I don't know how to
> force the attacker to rewind the entire disk, at the disk layer.
> (With cryptographic integrity checks in the file system, perhaps --
> how's ZFS on NetBSD coming?)

I'm of the opinion that integrity checking best belongs in the file
system layer because it necessarily involves increasing the size
of the data which for a pseudo-disk is very expensive indeed.  If
you decide to break a single disk write into multiple writes then
you must also necessarily maintain state on the disk of what you
are doing in case you crash in the midst of a write.  This would
involve turning each single sector write into at least three separate
writes.  At the file system layer, you have no such problem and
can preserve performance while also ensuring integrity.  (Unless
you can present 500 byte sectors to the rest of the kernel.)

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/