>>>>> "nw" == Nicolas Williams <nicolas.willi...@sun.com> writes: >>>>> "ch" == c hanover <chano...@umich.edu> writes:
Trying again:
ch> In our particular case, there won't be
ch> snapshots of destroyed filesystems (I create the snapshots,
ch> and destroy them with the filesystem).
Right, but if your zpool is above a zvol vdev (ex COMSTAR on another
box), then someone might take a snapshot of the encrypted zvol. Then
after you ``securely delete'' a filesystem by overwriting various
intermediate keys or whatever, they might roll back the zvol snapshot
to undelete.
Yes, you still need the passphrase to reach what they've undeleted,
but that's always true---what's ``secure delete'' supposed to mean
besides the ability to permanently remove one dataset but not others,
even from those who posess the passphrase? Otherwise it would not be
a feature. It would just be a suggestion: ``forget your passphrase.''
nw> ZFS crypto over zvols and what not presents no additional
nw> problems.
If you are counting on the ability to forget a key by overwriting the
block of vdev in which the key's stored, then doing it over zvol's is
an additional problem.
>> but for SSD,
Even if you do not have snapshots, SSD's are CoW internally so they
have something like latent snapshots from an attacker's perspective.
That is the point of my zvol example, which you are losing in your
``zvol's are just like devices, that's `abstraction,' I don't have to
think about it.''
ex., if your data lifecycle includes the idea that the ZFS crypto user
will securely delete things from devices before sent back for warranty
repair or reallocated to another group, whether it's SAN LUN's or
SSD's or zvol's or anythnig that has a copy-on-write character, then
from now on there is no such thing as overwriting. There is only
forgetting passphrases. This is both the case for using crypto in the
first place (overwriting blocks is no longer useful. Devices no
longer offer any command that can really erase them.), and also the
limitation of any ``Secure delete'' feature.
Example, my Chinese friend gives me a USB token and tells me the
passphrase. It has 'blah' stored on it. I create zfs filesystem
'blergh', write secret stuff to it, then ``securely delete'' it. I
return the token to my friend without fear the contents of 'blergh'
could escape because you've promised I've ``securely'' deleted it.
He takes the token to its manufacturer, loads diagnostic firmware,
rolls back the USB key to an earlier state using its CoW wear-leveling
feature, and recovers the ``securely deleted'' dataset.
so in these cases ``secure delete'' is meaningless. USB tokens are
common, and I don't know what is the use case of a ``secure delete''
feature rather than simply ``using passphrasese'', if not this one.
zfs crypto overall is not meaningless, but it depends on the
passphrase and is granular at whatever is protected by that
passphrase, no smaller, once CoW underneath.
If you have, (1) ability to change the passphrase whenver you like,
and (2) the passphrase can be not just a string a user types but it
can include a block of data read off a token, like LUKS, then with a
little bit of care you can have back secure erase over CoW backing
store. It depends on your ability to securely destroy the old block
of key material on this token when you change the passphrase and be
sure no one's saved an old copy of it. That's what I meant by
keystore outside the vdev structure.
Another scenario requiring something like secure delete which is
complicated by SSD's and zvol's underneath is to protect laptops
crossing borders. You may wish to make known that you routinely
revoke owners' access to their laptop drives prevent customs agents
from trying to harrass/detain people into handing over their
passphrases. You might do this by changing the passphrase before
travel then delivering the new passphrase to yourself over VPN once
you've passed customs. Then, you can safely give the old passphrase,
which is all you know. If the laptop contains an SSD then the old
passphrase is probably still useful to a customs agent who can extract
dirty blocks from beneath the SSD-fs, so you lose.
For the second scenario, the holy grail feature would be to have two
zpools on one vdev, encrypted with different keys. zpool A will have
a 'balloon' dataset reserving the blocks used by zpool B. zpool A
will have an encrypted ueberblock free of magic numbers and in a
nonstandard location, and will be the one with secret data on it.
zpool B will be normal and contain no holygrail features, should be
preloaded by you with an earlier snapshot of zpool A. If you were to
start using zpool B it would quietly overwrite and corrupt parts of
zpool A. so, the process would be:
zpool create B ssd
<load with nonsecret but bootable stuff>
zpool export B
zpool create -holygrailfeature -o tokenfile=/tmp/A-token A ssd
<automatically makes balloon dataset reserving used blocks of B>
<possibly stores B's txg counter to warn you from importing A if
B's been written since A was created>
cp /tmp/A-token /vpn <-- part of key and nonstandard blockno of ueberblock
You give the key to zpool B under duress. Either you can go to great
lengths and arrange for zpool B to appear well-used before departing,
or else you can try to claim ``we travel with stock installs, then
receive an incremental stream once we pass customs'' to justify the
oldness of the B duress pool.
The overall B/A system functions for other kinds of duress as well:
your passphrase might include a physical token, which you can destroy
if you become afraid, but now you can do this without making the
laptop entirely worthless for the rest of the trip since you can still
use the duress pool. Of course if that were the only goal there are
easier ways to achieve it, but I think this one's less mistake/leak
prone in practice.
pgpAMKroz2s9B.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
