On Mon, Dec 21, 2009 at 02:44:00PM -0800, Darren J Moffat wrote: > The IV generation when doing deduplication > is done by calculating an HMAC of the plaintext using a separate per > dataset key (that is also refreshed if 'zfs key -K' is run to rekey the > dataset). > [..] > In the case where deduplication is not enabled the IV generation uses a > compbination of the txg number, the object and blockid which complies > with the recommendations for IV generation for both CCM and GCM.
Aha! This was the crucial detail - that IV generation depends on the dedup setting. Makes perfect sense now, and seems like a sensible choice to enable a meaningful risk vs space tradeoff, rather than have mutually defeating features. One (obvious, and no doubt well dealt with) question: I presume the IV method is stored per block, similar to compression, such that changing the dedup setting doesn't cause decryption to use the wrong IV? > What do you mean by a replay attack? > What is being replayed and by whom? Replay of previous disk blocks, substituted for more recent contents, by an attacker who either has offline access to the disk or MITM access to the storage path. Contrived example: playing back an old disk block with a previous, compromised password, instead of the block with the new, changed password. Many disk encryption mechanisms don't provide integrity at all, in part because (other than some recent advanced crypto modes) it cost extra space and therefore brought many other complexities. Even those with some integrity may not defend strongly against this replay. ZFS clearly is game-changing, particularly with respect to integrity protections. With the hopefully-imminent introduction of zfs-crypto, it's worthwhile understanding where the interaction and boundary between protection-against-error and protection-against-malice falls. Including the txg ctr in the IV (for non-dedup) is clearly useful, as is CoW (which changes the block number), but how far does it go back up the tree? Coming back down the tree, when do I first encounter zfs-crypto, and what can I fiddle with on the way to bypass or defeat its ongoing protections? Put as a threat: I have access to your data pool (image). We'll ignore boot-time integrity issues for your rpool and zfs-crypto executable code, for now. We'll also assume, for simplicity, that I'm not trying to tamper with a live running pool. Perhaps I'm a malicious SAN admin, or the SAN admin hasn't locked down his infrastructure. Perhaps you left your usb widget at home and I used my ninja skills to break in. I want to tamper with your data, and for you to accept my changes without detection: With plain ZFS, I have a whole lot of other work to do than I would with normal filesystems, updating hash chains back up to the uberblock. It's tricky, but doesn't require any secrets. It's trivial if I don't need to rewrite history and can just commit a new txg. With ZFS-crypto, the question is how far the integrity protection is extended with the inclusion of keys. What kinds of attack can still be mounted without keys, particularly against metadata tampering? It's the difference between hash and hmac/signature, and what's included in each. One example threat scenario: what if I change the dataset properties to "crypto=off", will that cause future writes to be in plaintext? What would help a user notice? None of this is a criticism, zfs-crypto is never going to be a universal solution to all threats - it's about understanding its coverage and limitations. It's about deciding whether/which existing (much less convenient) defenses can be dropped in favour of this new hotness, as much as it is about which of those still provide value or which threats remain unprotected because no defense is available or economical. (Subject: changed accordingly) -- Dan.
pgpsJ7TCRawG2.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
