Daniel Carosone wrote:
Your parenthetical comments here raise some concerns, or at least eyebrows,
with me. Hopefully you can lower them again.
compress, encrypt, checksum, dedup.
(and you need to use zdb to get enough info to see the
leak - and that means you have access to the raw devices)
An attacker with access to the raw devices is the primary base threat model for
on-disk encryption, surely?
An attacker with access to disk traffic, via e.g. iSCSI, who can also deploy
dynamic traffic analysis in addition to static content analysis, and who also
has similarly greater opportunities for tampering, is another trickier threat
model.
It seems like entirely wrong thinking (even in parentheses) to dismiss an issue
as irrelevant because it only applies in the primary threat model.
I wasn't dismissing it I was pointing out that this wasn't something an
unprivilege end user could easily do.
If the risk is unacceptable then dedup shouldn't be enabled. For some
uses cases the risk is acceptable and for those use cases we want to
allow the use of dedup with encryption.
(and the way I have implemented the IV
generation for AES CCM/GCM mode ensures that the same
plaintext will have the same IV so the ciphertexts will match).
Again, this seems like a cause for concern. Have you effectively turned these fancy and carefully designed crypto modes back into ECB, albeit at a larger block size (and only within a dataset)?
No I don't believe I have. 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).
Let's consider copy-on-write semantics: with the above issue an attacker can
tell which blocks of a file have changed over time, even if unchanged blocks
have been rewritten.. giving even the static image attacker some traffic
analysis capability.
So if that is part of your deployment risk model deduplication is not
worth enabling in that case.
This would be a problem regardless of dedup, for the scenario where the
attacker can see repeated ciphertext on disk (unless the dedup metadata itself
is sufficiently encrypted, which I understand it is not).
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.
(you need to understand
what I've done with the AES CCM/GCM MAC
I'd like to, but more to understand what (if any) protection is given against
replay attacks (above that already provided by the merkle hash tree).
What do you mean by a replay attack ? What is being replayed and by whom ?
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
