zfs crypto discuss - Jul 2007 - ZFS Crypto Design review: 2007-07-02 through2007-07-16

Hiya folks,

My two penn''orth on the technical content...

Section 1, "Why are we doing this?": final bullet

I''m sure I''ve seen legal precedent where, the plaintiff having
discovered ciphertext, the defendant had to go through the process of  
decrypting the ciphertext with every key he was found to hold, in  
order to prove that he was not in possession of the appropriate key.  
I''m thinking that it may be useful to hold digests of deleted keys,  
and prepend / append the digest of a key to the ciphertext, to speed  
such a process up...

Section 2.2, final paragraph

Comparing / contrasting with Mac OS X FileVault, crypto can be  
enabled / disabled at any time provided that sufficient free disk  
space exists for two copies of the dataset (plus whatever workspace)  
to be stored. I guess we''re going to rely on the user to do the  
"lifting".

Section 2.3.3

I expect this is the mode which will be most widely used, in practice.

Section 3.1

There is also the issue of "storing your keys somewhere your data  
isn''t"; if the data and key are stored together, they can fall
into
the wrong hands together. What is the feasibility of storing per- 
dataset keys in something like a TPM?

Also, if the key is stored in the zvol, what is the mechanism by  
which the key can be identified as distinct from the general  
ciphertext, and extracted in order to mount the volume - is the plan  
to have a cleartext ueberblock extended to include a pointer to the  
location of the wrapped key, perhaps, or something else?

Section 3.1.1

This is hard - also, while the solution "will need to be extended for  
encryption so we know when it is safe to destroy the old keys", as is  
said, the reverse is true for ephemerisation - do we actively need to  
verify that the data to be "put beyond use" is encrypted with the  
verson of the key we''re about to destroy?

Section 3.2

Would clones thus be semi-automagically included in a re-keying  
process, provided the system doing the re-keying has access to them?

Section 3.3

If the key to the swap zvol is ephemeral, this means that swap can no  
longer be used for system crash dump storage; it will need to be made  
clear that crash dump management will need to be set up in an  
alternative manner before swap encryption is enabled.

Section 5.1.3

A typo, but technical ;-). I assume /var/tmp should be /tmp, in the  
last paragraph - and I also think that giving /tmp an ephemeral key  
is a good idea.

Section 5.2

Is there any possibility that a PIN could be stored on the system  
identification card (SPARC only, of course, but perhaps of interest)?

Also, while this mechanism works just fine provided all datasets are  
initially mounted in the global zone, it is likely to run into  
problems in the event that a non-global zone needs to do this itself;  
while appropriate privilege could be given to the non-global zone to  
access the device, it strikes me as "yet another good reason to  
mandate global-zone mounting" . This particularly applies to TX,  
where a zone would need to break MAC in order to access a key or a  
PIN mounted on Trusted Path.

Section 5.6

Is this also somewhere that the storage of the dataset-unlocking  
wrapped key should be discussed?

Section 6.3

See comments on Section 2.2.

Sections 6.4, 6.5

These appear to me as questions which remain open. I''ve put some  
effort into catching-up on the threads on the zfs-crypto-discuss  
alias, but I might have missed something - I think we need direct  
feedback from backup tool vendors.

Cheers,

--
Dave Walker
Client Solutions, Sun Microsystems UK
Tel: +44 780 3079264
http://blogs.sun.com/davew/

Dave Walker - Sun UK wrote:

[ I''ll come back to the others later but just a quick reply to some of 
your comments ]
> If the key to the swap zvol is ephemeral, this means that swap can no  
> longer be used for system crash dump storage; it will need to be made  
> clear that crash dump management will need to be set up in an  
> alternative manner before swap encryption is enabled.
Correct and the documentation will make that clear.
> Section 5.1.3
> 
> A typo, but technical ;-). I assume /var/tmp should be /tmp, in the  
> last paragraph - and I also think that giving /tmp an ephemeral key  
> is a good idea.
No I really did mean /var/tmp.  /var/tmp is normally disk backed. /tmp 
is tmpfs and thus swap backed so it gets covered by encrypted zvol for swap.

-- 
Darren J Moffat