Pawel Jakub Dawidek wrote:
>> [1] http://opensolaris.org/os/project/zfs-crypto/files/zfs-crypto.pdf
>
> Nice to see progress on that front.
>
> How do you plan to ask for passphrases exactly?
The initial phase will only have a single passphrase per pool, since all
we need is the passphrase to generate the unwrapping key that is used to
wrap the per dataset keys.
zpool(1M) will be interactive. There will also be an API for this in
libzfs and libzfs_jni.
I attempted to document this in Section 6 of the document.
> If keys are stored on a
> hardware, which is available immediately we could decrypt and mount
> datasets automatically on 'zfs mount -a',
That depends on the hardware and what kind of key object it is. Even in
the hardware case we may actually need the PIN to login to the hardware.
This is certainly true for the SCA-6000 card (and its predecessor the
SCA-4000).
It may well end up being different for a TPM though.
> but if someone has to enter a
> passphrase/pin, maybe we should just skip such datasets and allow to
> mount them manually later, when administrator is ready? That's the plan?
Thats what I'm hoping will work. In actual fact I think the mount might
work but you will get EIO on any attempt to access them until the key is
made available.
> I'm not sure I agree than CBC mode is not ok. It can be used in a secure
> way for data disk encryption and I think it should be done. The main
> reason is that there is a lot of h/w accelerators out there that already
> support CBC.
I'll get the rationale for this added to the document. I'm asking James
Hughes to write this up for me since the choice of CCM rather than CBC
is based heavily on his input.
> For some time now I'm thinking about encryption implementation at VDEV
> level. This should allow to encrypt more ZFS metadata, which may be
> desirable for some uses. Will it be possible to make the code
> responsible for encryption/decryption as much general as possible to
> make it usable for encryption at VDEV level (if you guys decide it makes
> sense)?
The functions that do the actual encrypt/decrypt are generic. They have
to be since I need to be able to deal with encrypting not only the data
but also things like dn_bonus in the dnode_phys_t.
One thing I would say is that the choice of AES mode may not be the same
if we did the encryption at the VDEV level rather than at the ZIO layer.
Doing it at the VDEV layer is more like doing what the loficc project
(or dm-crypt / cryptoloop on Linux, File Vault on MacOS X) does. There
AES CBC isn't a good choice.
> Do you have an analysis/list of things that won't be encrypted? What are
> the possible threats?
I have some of this but I'm not finished yet - it will be in the
document when I'm finished this part. At present I have:
Encrypted:
All ?application? data
POSIX layer data
Permissions, owner etc
Directory structure
All ZVOL data
Snapshots
Take parent policy
Clones[ Will have different key for non shared blocks]
Likely in Clear:
Pool metadata
VDEL layout, zpool history.
Open issue:
Data set names
Data set properties - probably need to encrypt all user properties.
> For example will it be possible to move blocks
> within a pool, which won't be discovered by ZFS?
How would you move blocks without ZFS noticing it given that we checksum
everything ? One of the things I haven't made a decision on yet is if
we should actually use HMAC-SHA256 when doing crypto instead of just
SHA256. The issue here is what happens when only some datasets are
encrypted.
--
Darren J Moffat
