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/ _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
