Re: RFC: backporting GEOM to the 4.x branch

[Roland Dowdeswell <elric@xxxxxxxxxx>]

On 1109715311 seconds since the Beginning of the UNIX epoch
"Steven M. Bellovin" wrote:
>

>It's worth noting that there is a very real threat not addressed here: 
>detecting unauthorized changes to an encrypted disk.  For a very 
>elegant solution, see http://www.isoc.org/isoc/conferences/ndss/05/proceedings
>/papers/storageint.pdf

I thought about this a little when I was writing CGD and decided
that since it would involve changing the block size or updating
multiple blocks when one block was modified that it would be handled
much better at the file system layer than at the disk layer.  E.g.
right now LFS uses a checksum to determine if a segment write has
fully completed upon recovery from a crash.  It would be easy to
modify that checksum into an HMAC.  That would provide integrity
protection almost for free.  If we did it at the disk level, then
we would be in the game of trying to make 2 disk writes appear
atomic which would be a serious performance problem.

On the other hand Thor Lancelot Simon made an interesting suggestion
recently, which was one could reformat the underlying disk to have
522 byte blocks but have CGD present 512 byte blocks to the layers
above it and still maintain the appropriate atomicity while gaining
a 160 bit HMAC for each block.

I think that the integrity checking has a more limited threat model,
namely only removable media (for NetBSD, at least).  If someone is
able to steal my laptop and return it, they could just bug the
keyboard much more quickly than figure out how to change my encrypted
partitions in a non-obvious way.  Or they could circumvent the boot
blocks, reflash the BIOS, etc. etc.  So, I think that this only
matters for media which is more likely to pass out of my direct
control than my laptop---or as in the article NAS/SAN architectures,
where the storage is not nec. coresident with the computer.

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