zfs crypto discuss - Jun 2007 - ZFS Crypto Design Review

The ZFS Crypto project is nearing completion of the design for phase 1.

A two week design review will be held starting with the publication of 
the phase 1 design document on Monday 2nd July.  I will also arrange a 
1hr conference call to discuss issues interactively.

Details of where to find the document, how to provide feedback and how 
to participate in the call will be posted on 
http://opensolaris.org/os/project/zfs-crypto by Monday 2nd July and will 
also be send to the zfs-crypto-discuss at opensolaris.org project alias.

-- 
Darren J Moffat

Darren,

The one item that I would like to see that IMHO adds a huge amount of value 
to the encryption equation is data protection.  By this I mean that once the 
encrypted volume is mounted, only users that know the private key can 
actually access the data even though the volume is mounted.

For example, lets say that root in the global zone creates and mounts 
an encrypted ZFS filesystem and populates it with some data.  Lets say 
that permissions permit read access to all the files in that filesystem.
If a user tries to open or view the contents of a file in that filesystem 
the contents of the file would be encrypted.  Only if they provide the 
private key can they see the un-encrypted view of the data.

Hope that makes sense.

Regards,
Brad
 
 
This message posted from opensolaris.org

On Mon, Jul 02, 2007 at 09:08:21PM -0700, Brad Diggs
wrote:
> The one item that I would like to see that IMHO adds a huge amount of value
> to the encryption equation is data protection.  By this I mean that once
the
> encrypted volume is mounted, only users that know the private key can 
> actually access the data even though the volume is mounted.
Once the keys (or use of thereof) are available to the host the problem
becomes a local security problem, not a cryptographic protocol one.

Incidentally, this makes me think that the design doc really needs to
lay out the threat models that apply to phase 1 and those subsequent
phases that can be outlined at this time.

For phase 1 I would think that the best threat model to consider is
theft of everything except a logged in HW token and/or the raw
keys/passphrases.  For such a model per-pool or per-vdev keys are more
than sufficient, methinks.

Nothing much can be done at the ZFS crypto layer about attacks that
subvert the host (e.g., get all privs, load a kernel module, wait until
keys are available, steal cleartext data, have fun).  Here per-dataset
keys slow the attacker, but if the attacker can wait long enough then
per-dataset keying won''t defeat it.

So what other threat models might the team consider?  Passive and active
attackers on the wire between the host and the storage media.  Again,
per-pool or per-vdev keying is more than sufficient here.  (iSCSI/IPsec
could help too if any of the metadata were to be in cleartext, though
ideally ZFS crypto should just provide an end-to-end confidentiality +
integrity protection solution and to hell with wasting cycles on crypto
in iSCSI/IPsec, a wonderful simplification that!)

So I''m wondering what the case for per-dataset keying really is. 
I''m
not sure that I see enough value in slowing down a local attacker with
all privileges to justify per-dataset keying.  Perhaps others do?

Nor do I think that by having separate per-dataset keys for data and
metadata we could have backup tools other than zfs send/receive actually
backup ciphertext that can be restored -- backup tools that are not
intimate with the ZFS ondisk format will not be able to backup, much
less restore blkptr_t values with the correct MACs/checksums.

The zfs send/receive use case does seem to justify having per-dataset
keying -- it saves cycles on backup restore (no need to decrypt data on
backup and reencrypt before hitting backup media; similarly on receive),
unless you want to re-key on send/receive.  But I''m not sure that the
resulting complexity helps make the case for per-dataset keying.

Secure deletion is a feature that could argue, in the extreme, for
per-file data keying, if per-file secure deletion is desired.  In that
case we could have per-dnode keying for file data + per-pool or vdev
keying for everything else.  But note that in this case the per-file key
would be there only for secure deletion, not for protection against
various attackes, therefore it would not be necessary to key any MACs
with per-file keys (though one might want to anyways, else AE cipher
modes need not apply unless the cipher/mode can use separate integrity
and confidentiality keys).

I asked offline how dataset destruction works: it traverses the dataset
metadata to find and release all blocks that can be released.  This
means that we really MUST have quite a bit (but not all) of a dataset''s
metadata in cleartext relative to the containing pool (i.e., it may be
encrypted with a key that is always available to the host whenever the
pool''s master keys are available to the host).  Directory contents,
ACLs, it seems to me, need not be, but the dnode file and all bits of
metadata containing blkptr_t''s need to be.

Therefore I propose that the threat model for phase 1 be media theft and
attackers on the wire between the host and the media.  Therefore I also
propose that per-pool or per-vdev keying be pursued.  Secure file
deletion could be left out of scope, else per-dataset or per-file data
keying will be needed as well.

BTW, using per-vdev keying has its advantages.  For example: re-keying
is as simple as adding new vdevs, scrubbing, then removing old ones.

All that said, in all cases we''d still need keyed MACs (or authen. tags
from AE ciphers/cipher modes) instead of checksums.  I think that in all
cases it should be possible to determine from the context of a blkptr_t
what key(s) and cipher/mode encrypts the block(s) it points to.  So the
ondisk format should change very little -- new MACs, new props, new
rules for some things and the encryption transformation, but that should
be mostly it, with blkptr_t and dnode*_t left unchanged.

Nico
--

Nicolas Williams wrote:
> Therefore I propose that the threat model for phase 1 be media theft and
> attackers on the wire between the host and the media.  Therefore I also
> propose that per-pool or per-vdev keying be pursued.  Secure file
> deletion could be left out of scope, else per-dataset or per-file data
> keying will be needed as well.
Which is exactly what the model for phase 1 is and is basically what is 
is stated in the "Why are we doing this?" part of section 1 of the 
design doc.  I don''t believe I made that anywhere clear enough so
thanks
for the prompt.

*AI Darren*:  I''ll update that section to make it a threat model 
discussion and clarify what is and is not in scope.


I looked at per-vdev but based on my understanding it wouldn''t actually
have been any easier to implement than doing the crypto in the ZIO 
pipeline.  Having crypto in the ZIO pipeline now means this can be used 
as the basis for the future phases of this project.

However the most important reason for having the policy per dataset 
rather than per vdev is to allow for deployments where only a subset of 
the data needs to be encrypted.  The reason for using a wrapping key 
rather than the same key for every data set is so that different 
algorithms and keylengths can be supported by phase 1 in the same pool. 
  I know of customer deployments where this will be used.
> BTW, using per-vdev keying has its advantages.  For example: re-keying
> is as simple as adding new vdevs, scrubbing, then removing old ones.
Then physically destroying or otherwise doing a secure erase on the old 
vdev.  True but I think in practice it wouldn''t actually be that easy.

-- 
Darren J Moffat

Brad Diggs wrote:
> Darren,
> 
> The one item that I would like to see that IMHO adds a huge amount of value
> to the encryption equation is data protection.  By this I mean that once
the
> encrypted volume is mounted, only users that know the private key can 
> actually access the data even though the volume is mounted.
Phase 1 ZFS crypto does not allow for per user keying.

End users never see or hold keys in Phase 1 ZFS crypto.
> For example, lets say that root in the global zone creates and mounts 
> an encrypted ZFS filesystem and populates it with some data.  Lets say 
> that permissions permit read access to all the files in that filesystem.
> If a user tries to open or view the contents of a file in that filesystem 
> the contents of the file would be encrypted.  Only if they provide the 
> private key can they see the un-encrypted view of the data.
ZFS crypto does not use public/private key pairs.

Functionality like this maybe considered for a future phase, even if it 
isn''t implemented exactly like you suggest.

-- 
Darren J Moffat

Some comments on the ZFS crypto design document:

* Encryption policy
   -  I''m not understanding why it is not possible to toggle the on/off
encryption property on a dataset once it is defined.  I think this might be
viewed as a problem, or at least a minor-annoyance,  in the future.   When the
Key Change feature (section 3.1.1) is implemented, perhaps that solution would
also make it possible to toggle the crypto since it is a similar operation.

* Key Mgmt
   - The keys for all datasets associated with a pool are encrypted in the
master key for that pool. Individual dataset keys are randomly generated.  So,
the person with the master pool key can unlock any of the underlying datasets. 
Is it possible for an individual to give their own key (rather than getting a
wrapped, random key) when creating a new dataset so that the person with the
pool master key could NOT view their data? Those "private" datasets
would require prompting when the zfs-mount is issued so that the user could
enter the correct key (or path to a keyfile or LABEL of a key stored on a
token).  I was thinking of a model similar to what we use internally on our
devel system where individuals can create their own datasets - could users
create their own, private, datasets that the admin could not decrypt?

* Pool: setkey
  - How does ZFS identify the master keys if they are stored on a hardware token
- is there a unique naming convention (i.e. the key objects CKA_LABEL attribute)
that is used to identify the pool keys?
 
* Key Modes:
   - Is this feature extensible for the future so that if we come up with
different key mgmt methods, they could be easily added ?   I''m thinking
of some more complex key management solutions such as a centralized KM service
that might require additional parameters to access the keys.


-Wyllys Ingersoll
 
 
This message posted from opensolaris.org

Wyllys Ingersoll wrote:
> Some comments on the ZFS crypto design document:
> 
> * Encryption policy -  I''m not understanding why it is not
possible
> to toggle the on/off encryption property on a dataset once it is
> defined.  I think this might be viewed as a problem, or at least a
> minor-annoyance,  in the future.   When the Key Change feature
> (section 3.1.1) is implemented, perhaps that solution would also make
> it possible to toggle the crypto since it is a similar operation.
Yes, since they are largely the same exercise, it is better to wait 
until we have Key Change..
> * Pool: setkey - How does ZFS identify the master keys if they are
> stored on a hardware token - is there a unique naming convention
> (i.e. the key objects CKA_LABEL attribute) that is used to identify
> the pool keys?
The master key''s CKA_LABEL is currently designed to be the GUID of the 
pool..  Which from what I understand is unique and permanent.

> * Key Modes: - Is this feature extensible for the future so that if
> we come up with different key mgmt methods, they could be easily
> added ?   I''m thinking of some more complex key management
solutions
> such as a centralized KM service that might require additional
> parameters to access the keys.
The two modes are just phase 1.  Future phases could contain additional 
modes..

Tony

Wyllys Ingersoll wrote:
> Some comments on the ZFS crypto design document:
> 
> * Encryption policy
>    -  I''m not understanding why it is not possible to toggle the
on/off encryption property on a dataset once it is defined.  I think this might
be viewed as a problem, or at least a minor-annoyance,  in the future.   When
the Key Change feature (section 3.1.1) is implemented, perhaps that solution
would also make it possible to toggle the crypto since it is a similar
operation.
The reason you can''t turn crypto on and off at will for a given data
set
is because unlike compression it actually matters if all the blocks are 
written encrypted or not.  Consider this:

At time t0 I do:
	zfs create home/darrenm/Documents
	
At time t1 before any data is written I do

	zfs set -o encryption=aes-128-cbc home/darrenm/Documents

At time t2 I put some really private data into that directory, and all 
the blocks in it get encrypted.

At time t3 I or an admin does this:

	zfs set -o encryption=off home/darrenm/Documents

I update that private document (lets say I didn''t actually hit save but
an application auto-save happened), but it causes only part of the file 
to get rewritten so some blocks are encrypted and some are in the clear.

At time t4 I or the admin notices our boo-boo and does

	zfs set -o encryption=on home/darrenm/Documents

Question is am I safe ?

Answer no you aren''t because at time t3 cleartext blocks got written 
out.  However I can''t tell using the zfs(1) command that this happened,
in fact I have very little change of knowing that happened.

Now if this was compression, it really doesn''t mater all that happens
is
that blocks that may have been compressed aren''t so it is just a 
cpu/diskspace trade off.   With crypto its a security issue.

Even if we had the ability to go and write new versions of all the clear 
text blocks we still need a way to overwrite them with a suitable secure 
pattern (maybe N times) to make them safe.

There are similar problems with just changing between various values of 
encryption that all imply doing something other than cleartext.  This is 
because it isn''t always possible to say that one 
algorithm/keylength/mode is stronger than another, and if they need 
different keys you have to keep all the keys around.


-- 
Darren J Moffat

Wyllys Ingersoll wrote:
> * Key Modes:
>    - Is this feature extensible for the future so that if we come up with
different key mgmt methods, they could be easily added ?   I''m thinking
of some more complex key management solutions such as a centralized KM service
that might require additional parameters to access the keys.
Very much so.  This is the reason there is a property to store this.

I hope that we can even support changing the key management for a given 
dataset when new keymode settings are added.  Though it may not be 
possible, due to restrictions in the key managment system, to 
arbitrarily migrate between all values.


--
Darren J Moffat

Darren J Moffat wrote:
>  Wyllys Ingersoll wrote:
> > Some comments on the ZFS crypto design document:
> >
> > * Encryption policy -  I''m not understanding why it is not
possible
> > to toggle the on/off encryption property on a dataset once it is
> > defined.  I think this might be viewed as a problem, or at least a
> > minor-annoyance,  in the future.   When the Key Change feature
> > (section 3.1.1) is implemented, perhaps that solution would also
> > make it possible to toggle the crypto since it is a similar
> > operation.
>
>  The reason you can''t turn crypto on and off at will for a given
data
>  set is because unlike compression it actually matters if all the
>  blocks are written encrypted or not.  Consider this:
>
>  At time t0 I do: zfs create home/darrenm/Documents
>
>  At time t1 before any data is written I do
>
>  zfs set -o encryption=aes-128-cbc home/darrenm/Documents
>
>  At time t2 I put some really private data into that directory, and
>  all the blocks in it get encrypted.
>
>  At time t3 I or an admin does this:
>
>  zfs set -o encryption=off home/darrenm/Documents
>
>  I update that private document (lets say I didn''t actually hit
save
>  but an application auto-save happened), but it causes only part of
>  the file to get rewritten so some blocks are encrypted and some are
>  in the clear.
>
>  At time t4 I or the admin notices our boo-boo and does
>
>  zfs set -o encryption=on home/darrenm/Documents
>
>  Question is am I safe ?
>
>  Answer no you aren''t because at time t3 cleartext blocks got
written
>  out.  However I can''t tell using the zfs(1) command that this
>  happened, in fact I have very little change of knowing that happened.

OK.  What if the zfs command restricted the use of the encryption flag
by only making it possible to change the value when that filesystem was
not currently mounted?   That would prevent the above scenario
and still leave it possible to make the change, albeit under strict
conditions.

-Wyllys

>
>
>  Now if this was compression, it really doesn''t mater all that
happens
>  is that blocks that may have been compressed aren''t so it is just
a
>  cpu/diskspace trade off.   With crypto its a security issue.
>
>  Even if we had the ability to go and write new versions of all the
>  clear text blocks we still need a way to overwrite them with a
>  suitable secure pattern (maybe N times) to make them safe.
>
>  There are similar problems with just changing between various values
>  of encryption that all imply doing something other than cleartext.
>  This is because it isn''t always possible to say that one
>  algorithm/keylength/mode is stronger than another, and if they need
>  different keys you have to keep all the keys around.
>
>

Wyllys Ingersoll wrote:
> OK.  What if the zfs command restricted the use of the encryption flag
> by only making it possible to change the value when that filesystem was
> not currently mounted?   That would prevent the above scenario
> and still leave it possible to make the change, albeit under strict
> conditions.
That doesn''t actually help.  Consider this.

t0:  zfs create home/wyllys/Documents
t1:  Write sensitive stuff to file on Documents
t2:  zfs umount home/wyllys/Documents
t3:  zfs set encryption=on home/wyllys/Documents
t4:  zfs mount home/wyllys/Documents
t5:  zfs get encryption home/wyllys/Documents

At time t5 you will be told that encryption is on but are you safe ?

You don''t know because you don''t know what the value of
encryption was
for every block in that dataset all you know is the current value.

The problem is one of observability we do not want to lie to the user 
about wither or not data in a given dataset is encrypted.  Unless we 
know encryption has always been on then we can''t ever say it is on.  At
least no until ZFS provides a framework to rewrite every single block in 
a dataset, and even then you will need a way to know that that has 
completed AND that all the old cleartext blocks have been bleached 
(scrubbed but ZFS uses scrub to mean verify checksums) to be some save 
value.


I understand your concern on usability but this in my opinion is one 
area where usability needs to be bow to security otherwise people might 
think they are safe when they really aren''t.

-- 
Darren J Moffat

On Tue, Jul 10, 2007 at 04:21:13PM +0100, Darren J Moffat
wrote:
> Wyllys Ingersoll wrote:
> > OK.  What if the zfs command restricted the use of the encryption flag
> > by only making it possible to change the value when that filesystem
was
> > not currently mounted?   That would prevent the above scenario
> > and still leave it possible to make the change, albeit under strict
> > conditions.
> 
> That doesn''t actually help.  Consider this.
Right.  The only time you should be able to change the keys are when the
filesystem is *empty* (but even then, there''s plenty of stuff to
re-encrypt, like the root dnode, the dnode file, etc...), so empty that
it''s not even been created :)  or when it''s being re-keyed,
which is out
of scope for phase 1.

Now, I''m still not sure that we should expose anything about
per-dataset
keying yet.  I''m still not convinced that we shouldn''t have
per-vdev
keying.

Darren J Moffat wrote:
>  Wyllys Ingersoll wrote:
> > OK.  What if the zfs command restricted the use of the encryption
> > flag by only making it possible to change the value when that
> > filesystem was not currently mounted?   That would prevent the
> > above scenario and still leave it possible to make the change,
> > albeit under strict conditions.
>
>  That doesn''t actually help.  Consider this.
>
>  t0:  zfs create home/wyllys/Documents t1:  Write sensitive stuff to
>  file on Documents t2:  zfs umount home/wyllys/Documents t3:  zfs set
>  encryption=on home/wyllys/Documents t4:  zfs mount
>  home/wyllys/Documents t5:  zfs get encryption home/wyllys/Documents
>
>  At time t5 you will be told that encryption is on but are you safe ?
>
>  You don''t know because you don''t know what the value of
encryption
>  was for every block in that dataset all you know is the current
>  value.
>
>  The problem is one of observability we do not want to lie to the user
>  about wither or not data in a given dataset is encrypted.  Unless we
>  know encryption has always been on then we can''t ever say it is
on.
>  At least no until ZFS provides a framework to rewrite every single
>  block in a dataset, and even then you will need a way to know that
>  that has completed AND that all the old cleartext blocks have been
>  bleached (scrubbed but ZFS uses scrub to mean verify checksums) to be
>  some save value.

OK, that makes it clearer.   I didn''t know that ZFS did not provide a
method
for rewriting all of the blocks.
>
>
>  I understand your concern on usability but this in my opinion is one
>  area where usability needs to be bow to security otherwise people
>  might think they are safe when they really aren''t.
>
OK, I understand a little better now. 

Thanks,
-Wyllys

Nicolas Williams wrote:
> On Tue, Jul 10, 2007 at 04:21:13PM +0100, Darren J Moffat wrote:
>> Wyllys Ingersoll wrote:
>>> OK.  What if the zfs command restricted the use of the encryption
flag
>>> by only making it possible to change the value when that filesystem
was
>>> not currently mounted?   That would prevent the above scenario
>>> and still leave it possible to make the change, albeit under strict
>>> conditions.
>> That doesn''t actually help.  Consider this.
> 
> Right.  The only time you should be able to change the keys are when the
> filesystem is *empty* (but even then, there''s plenty of stuff to
> re-encrypt, like the root dnode, the dnode file, etc...), so empty that
> it''s not even been created :)  or when it''s being
re-keyed, which is out
> of scope for phase 1.
> 
> Now, I''m still not sure that we should expose anything about
per-dataset
> keying yet.  I''m still not convinced that we shouldn''t
have per-vdev
> keying.
The reason for exposing it is a cpu vs data security tradeoff.  It is 
also needed so that in cases where you are booting from the same pool 
your data is in (quite likely in a laptop) you can mark which datasets 
get encrypted and which don''t.  For example I can''t in phase 1
have an
encrypted root but I could have my home dir encrypted, I wouldn''t want 
my OpenSolaris ONNV builds area encrypted because thats all open source 
anyway so whats the point.


-- 
Darren J Moffat

On Tue, Jul 10, 2007 at 04:33:26PM +0100, Darren J Moffat
wrote:
> Nicolas Williams wrote:
> >Now, I''m still not sure that we should expose anything about
per-dataset
> >keying yet.  I''m still not convinced that we
shouldn''t have per-vdev
> >keying.
> 
> The reason for exposing it is a cpu vs data security tradeoff.  It is 
True, per-vdev keys -> more cycles spent on crypto, at least when
writing.  I think this is probably the best argument against per-vdev
keying; it''s the one that wins me.
> also needed so that in cases where you are booting from the same pool 
> your data is in (quite likely in a laptop) you can mark which datasets 
> get encrypted and which don''t.  For example I can''t in
phase 1 have an
> encrypted root but I could have my home dir encrypted, I wouldn''t
want
> my OpenSolaris ONNV builds area encrypted because thats all open source 
> anyway so whats the point.
Per-vdev keying does not imply encrypting the blocks of all datasets --
it implies only that the keys used to encrypt and authenticate blocks
are associated with the vdevs rather than with the datasets.  You could
still have datasets that don''t encrypt their blocks and datasets that
do.

The main benefit of associating keys with vdevs is that you get
re-keying and secure media deletion (well, of encrypted datasets)
automatically (the former via the existing pool scrub facility, the
latter via flushing all traces of the relevant keys as an extension to
zpool detach, perhaps).

The main drawback of per-vdev keying is the perf cost.

So pushing re-keying and secure deletion to future phases seems good
enough.

Nico
--

Hi Darren and all,

I have briefly scanned through the ZFS Encryption Project draft and here 
are my notes gathered during metro/subway trip:

   - what is the interaction of ZFS crypto policy model with ZFS 
delegated administration ?
     - say administrator could only allow user datasets to be created 
with encryption=on and maybe with key lengths not less than X bits
   - has anyone thought if 2-factor authentication can be applied to ZFS 
crypto project ?
   - do we want to keep track of how many times a dataset was zfs-sent 
in order to perform secure deletion ? (it is obvious that this would not 
be very helpful but at least warn the user that there might be non-local 
copies out there)


v.

Vladimir Kotal wrote:
> Hi Darren and all,
> 
> I have briefly scanned through the ZFS Encryption Project draft and here 
> are my notes gathered during metro/subway trip:
> 
>    - what is the interaction of ZFS crypto policy model with ZFS 
> delegated administration ?
Just like other properties you will be able to delegate wither or not a 
user an manipulate that property.
>      - say administrator could only allow user datasets to be created 
> with encryption=on and maybe with key lengths not less than X bits
I think we can do part of this, in that we can say that you can or
can''t
set the encryption property but best I can tel delegated admin does not 
give us the ability to control the actual values of properties only 
wither setting them can be delegated.
>    - has anyone thought if 2-factor authentication can be applied to ZFS 
> crypto project ?
Yes, lots :-)

Exactly what is the use case and what is the risk you are protecting 
against ?
>    - do we want to keep track of how many times a dataset was zfs-sent 
> in order to perform secure deletion ? (it is obvious that this would not 
> be very helpful but at least warn the user that there might be non-local 
> copies out there)
I don''t see any point in that since you can just as easily create clear
text non local copies with: cat, cp, tar, cpio, scp, sftp, etc etc.  It 
also doesn''t help with secure deletion.  I see what you are hinting at 
though, and that is that secure deletion isn''t just about the blocks in
the dataset but about all other possible copies.  I believe that that is 
better dealt with by other layers in the system, in some cases maybe 
using TX labels to control where the clear-text can go to.

--
Darren J Moffat

Darren J Moffat wrote:

<snip>
>>    - has anyone thought if 2-factor authentication can be applied to 
>> ZFS crypto project ?
> 
> Yes, lots :-)
> 
> Exactly what is the use case and what is the risk you are protecting 
> against ?
Basically from a scenario where I only store the dataset key on a 
hardware device (i.e. USB stick) and it gets stolen. This opens up the 
door to other problems (rekeying) but let''s say it''s
sufficient to have
the key protected at least somehow in this case.


v.

On Tue, Jul 10, 2007 at 04:33:26PM +0100, Darren J Moffat
wrote:
> Nicolas Williams wrote:
> > On Tue, Jul 10, 2007 at 04:21:13PM +0100, Darren J Moffat wrote:
> >> Wyllys Ingersoll wrote:
> >>> OK.  What if the zfs command restricted the use of the
encryption flag
> >>> by only making it possible to change the value when that
filesystem was
> >>> not currently mounted?   That would prevent the above scenario
> >>> and still leave it possible to make the change, albeit under
strict
> >>> conditions.
> >> That doesn''t actually help.  Consider this.
> > 
> > Right.  The only time you should be able to change the keys are when
the
> > filesystem is *empty* (but even then, there''s plenty of stuff
to
> > re-encrypt, like the root dnode, the dnode file, etc...), so empty
that
> > it''s not even been created :)  or when it''s being
re-keyed, which is out
> > of scope for phase 1.
> > 
> > Now, I''m still not sure that we should expose anything about
per-dataset
> > keying yet.  I''m still not convinced that we
shouldn''t have per-vdev
> > keying.
> 
> The reason for exposing it is a cpu vs data security tradeoff.  It is 
> also needed so that in cases where you are booting from the same pool 
> your data is in (quite likely in a laptop) you can mark which datasets 
> get encrypted and which don''t.  For example I can''t in
phase 1 have an
> encrypted root but I could have my home dir encrypted, I wouldn''t
want
> my OpenSolaris ONNV builds area encrypted because thats all open source 
> anyway so whats the point.
BTW. Do you plan do add integrity verification without encryption?
OpenSolaris source on your laptop may be open-source, but you don''t
want
someone to mess with them and then you commit some evil change to the
main source tree:) Beeing able to setup HMAC as checksum algorithm, but
without encryption might be useful sometimes.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-crypto-discuss/attachments/20070712/bfb56772/attachment.bin>

Pawel Jakub Dawidek wrote:
> BTW. Do you plan do add integrity verification without encryption?
> OpenSolaris source on your laptop may be open-source, but you
don''t want
> someone to mess with them and then you commit some evil change to the
> main source tree:) Beeing able to setup HMAC as checksum algorithm, but
> without encryption might be useful sometimes.
Since using an CBC mode for encryption requires we add an hmac-sha256 
variant yes.  I just didn''t make it explicit that hmac-sha256 will be 
available as a dataset checksum algorithm even when encryption=off.

Thanks for noticing that.

-- 
Darren J Moffat

On Thu, Jul 12, 2007 at 04:43:43PM +0100, Darren J Moffat
wrote:
> Pawel Jakub Dawidek wrote:
> >BTW. Do you plan do add integrity verification without encryption?
> >OpenSolaris source on your laptop may be open-source, but you
don''t want
> >someone to mess with them and then you commit some evil change to the
> >main source tree:) Beeing able to setup HMAC as checksum algorithm, but
> >without encryption might be useful sometimes.
> 
> Since using an CBC mode for encryption requires we add an hmac-sha256 
> variant yes.  I just didn''t make it explicit that hmac-sha256 will
be
> available as a dataset checksum algorithm even when encryption=off.
As long as the pool "owns" all the keys this is fine (and BTW,
we''ll
need AEAD cipher modes to support integrity-check-only, so no decryption
is needed during scrubs).

But I''m not sure that we''ll always want the pool to own all
the keys in
future enhancements.  I think we should reserve space in blkptr_t for
*two* checksums: one that the pool can use, one that the owner of the
keys (if not the pool) can use.  If we never need that space then we can
relinquish it to other potential users of it.

Nico
--

Would you consider configuring both the encryption and integrity
checking combinations as a "crypto suite" instead of having to hide
what
integrity checks are or are not used or configuring them separately?

That way it is clear in the configuration what is being used. One set of
crypto suites could have "null" encryption (confidentiality) used.

Larry H
 

-----Original Message-----
From: zfs-crypto-discuss-bounces at opensolaris.org
[mailto:zfs-crypto-discuss-bounces at opensolaris.org] On Behalf Of Darren
J Moffat
Sent: Thursday, July 12, 2007 9:44 AM
To: Pawel Jakub Dawidek
Cc: Wyllys Ingersoll; Nicolas Williams;
zfs-crypto-discuss at opensolaris.org
Subject: Re: [zfs-crypto-discuss] ZFS Crypto Design Review

Pawel Jakub Dawidek wrote:
> BTW. Do you plan do add integrity verification without encryption?
> OpenSolaris source on your laptop may be open-source, but you
don''t
> want someone to mess with them and then you commit some evil change to
> the main source tree:) Beeing able to setup HMAC as checksum 
> algorithm, but without encryption might be useful sometimes.
Since using an CBC mode for encryption requires we add an hmac-sha256
variant yes.  I just didn''t make it explicit that hmac-sha256 will be
available as a dataset checksum algorithm even when encryption=off.

Thanks for noticing that.

--
Darren J Moffat
_______________________________________________
zfs-crypto-discuss mailing list
zfs-crypto-discuss at opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss

I just have a (naive) question about the master key storage.  

As stated in section 2.3.2 that all the ZFS encryption can be supported in
software only.   I guess in this situation, the master  key will be stored in a
Solaris softtoken keystore, correct ?
If correct, then the disk that containing the Solaris softtoken keystore should
be different from
the pool to be encrypted.   Does the disk for the Solaris softtoken keystore can
be different file system type ?

Thanks,
Huie-Ying
 
 
This message posted from opensolaris.org

Huie-Ying Lee wrote:
> I just have a (naive) question about the master key storage.  
> 
> As stated in section 2.3.2 that all the ZFS encryption can be supported in
software only.
 > I guess in this situation, the master  key will be stored in a Solaris
 > softtoken keystore, correct ?

That is one possibility.  The other this that the masker key is dervied 
from a passphrase using PKCS#5 PBE.  Or the master key is stored as a 
plain file.
> If correct, then the disk that containing the Solaris softtoken keystore 
 > should be different from the pool to be encrypted.

Operationally yes may be best.  In some cases the softoken keystore 
files may actually be stored on removable media - such as a small USB 
mass storage device.

 > Does the disk for the Solaris softtoken keystore can be different
 > file system type ?

I don''t understand what you are asking here.  Different type to what ?

--
Darren J Moffat

Darren J Moffat wrote:
> Huie-Ying Lee wrote:
>> I just have a (naive) question about the master key storage. 
>> As stated in section 2.3.2 that all the ZFS encryption can be 
>> supported in software only.   
>  > I guess in this situation, the master  key will be stored in a
Solaris
>  > softtoken keystore, correct ?
> 
> That is one possibility.  The other this that the masker key is dervied 
> from a passphrase using PKCS#5 PBE.  Or the master key is stored as a 
> plain file.
> 
>> If correct, then the disk that containing the Solaris softtoken
keystore
>  > should be different from the pool to be encrypted.
> 
> Operationally yes may be best.  In some cases the softoken keystore 
> files may actually be stored on removable media - such as a small USB 
> mass storage device.
> 
Aah!  Good to know this.  Currently, softtoken keystore files live
in the disk only.  I assume that it will need some enhancement to
the Solaris softtoken keystore to be supported on Removable media.

>  > Does the disk for the Solaris softtoken keystore can be different
>  > file system type ?
> 
> I don''t understand what you are asking here.  Different type to
what ?
> 
I meant different file systems, for example, UFS.
> -- 
> Darren J Moffat
Thanks,
Huie-Ying

Huie-Ying Lee wrote:
> Darren J Moffat wrote:
>> Huie-Ying Lee wrote:
>>> I just have a (naive) question about the master key storage. 
>>> As stated in section 2.3.2 that all the ZFS encryption can be 
>>> supported in software only.   
>>  > I guess in this situation, the master  key will be stored in a
Solaris
>>  > softtoken keystore, correct ?
>>
>> That is one possibility.  The other this that the masker key is dervied
>> from a passphrase using PKCS#5 PBE.  Or the master key is stored as a 
>> plain file.
>>
>>> If correct, then the disk that containing the Solaris softtoken
keystore
>>  > should be different from the pool to be encrypted.
>>
>> Operationally yes may be best.  In some cases the softoken keystore 
>> files may actually be stored on removable media - such as a small USB 
>> mass storage device.
>>
> 
> Aah!  Good to know this.  Currently, softtoken keystore files live
> in the disk only.  I assume that it will need some enhancement to
> the Solaris softtoken keystore to be supported on Removable media.
If an alternative keystore (SOFTTOKEN_DIR) is used, there will be no 
additional changes needed for removable media..
> 
> 
>>  > Does the disk for the Solaris softtoken keystore can be different
>>  > file system type ?
>>
>> I don''t understand what you are asking here.  Different type
to what ?
>>
> 
> I meant different file systems, for example, UFS.
> 
>> -- 
>> Darren J Moffat
> 
> Thanks,
> Huie-Ying
> _______________________________________________
> zfs-crypto-discuss mailing list
> zfs-crypto-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-crypto-discuss

Huie-Ying Lee wrote:
> Darren J Moffat wrote:
>> Huie-Ying Lee wrote:
>>> I just have a (naive) question about the master key storage. 
>>> As stated in section 2.3.2 that all the ZFS encryption can be 
>>> supported in software only.   
>>  > I guess in this situation, the master  key will be stored in a
Solaris
>>  > softtoken keystore, correct ?
>>
>> That is one possibility.  The other this that the masker key is dervied
>> from a passphrase using PKCS#5 PBE.  Or the master key is stored as a 
>> plain file.
>>
>>> If correct, then the disk that containing the Solaris softtoken
keystore
>>  > should be different from the pool to be encrypted.
>>
>> Operationally yes may be best.  In some cases the softoken keystore 
>> files may actually be stored on removable media - such as a small USB 
>> mass storage device.
>>
> 
> Aah!  Good to know this.  Currently, softtoken keystore files live
> in the disk only.  I assume that it will need some enhancement to
> the Solaris softtoken keystore to be supported on Removable media.
Removable media (aka USB and 1394 mass storage devices) are just 
filesystems, they often use flash memory rather than spinning rust. 
However as far as Solaris is concerned is just a disk.
>>  > Does the disk for the Solaris softtoken keystore can be different
>>  > file system type ?
>>
>> I don''t understand what you are asking here.  Different type
to what ?
>>
> 
> I meant different file systems, for example, UFS.
The softtoken keystore works just fine on ZFS and I''m pretty sure
I''ve
used it on PCFS (FAT) as well but I''d need to double check it and run 
the test suite to be sure it is okay.

--
Darren J Moffat

Darren J Moffat wrote:
> Huie-Ying Lee wrote:
>> Darren J Moffat wrote:
>>> Huie-Ying Lee wrote:
>>>> I just have a (naive) question about the master key storage. As
>>>> stated in section 2.3.2 that all the ZFS encryption can be
supported
>>>> in software only.   
>>>  > I guess in this situation, the master  key will be stored in
a
>>> Solaris
>>>  > softtoken keystore, correct ?
>>>
>>> That is one possibility.  The other this that the masker key is 
>>> dervied from a passphrase using PKCS#5 PBE.  Or the master key is 
>>> stored as a plain file.
>>>
>>>> If correct, then the disk that containing the Solaris softtoken
>>>> keystore 
>>>  > should be different from the pool to be encrypted.
>>>
>>> Operationally yes may be best.  In some cases the softoken keystore
>>> files may actually be stored on removable media - such as a small
USB
>>> mass storage device.
>>>
>>
>> Aah!  Good to know this.  Currently, softtoken keystore files live
>> in the disk only.  I assume that it will need some enhancement to
>> the Solaris softtoken keystore to be supported on Removable media.
> 
> Removable media (aka USB and 1394 mass storage devices) are just 
> filesystems, they often use flash memory rather than spinning rust. 
> However as far as Solaris is concerned is just a disk.
> 
>>>  > Does the disk for the Solaris softtoken keystore can be
different
>>>  > file system type ?
>>>
>>> I don''t understand what you are asking here.  Different
type to what ?
>>>
>>
>> I meant different file systems, for example, UFS.
> 
> The softtoken keystore works just fine on ZFS and I''m pretty sure
I''ve
> used it on PCFS (FAT) as well but I''d need to double check it and
run
> the test suite to be sure it is okay.
> 
> -- 
> Darren J Moffat
Right, thanks for the clarification.

Huie-ying