zfs crypto discuss - Jul 2007 - additional comments on design doc

Hello,
    I''ve attached a marked up design doc. Happy to discuss any or all. 
 
I did not go back and try to see if the comments have been addressed in
any of the e-mail threads, but I don''t think they all have been talked
about on this reflector since the document was posted.
 
Larry H
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-crypto-discuss/attachments/20070716/a156a67d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zfs-crypto-designLDHComments.pdf
Type: application/octet-stream
Size: 266384 bytes
Desc: zfs-crypto-designLDHComments.pdf
URL:
<http://mail.opensolaris.org/pipermail/zfs-crypto-discuss/attachments/20070716/a156a67d/attachment.obj>

Hello,
Here is the text file version of the same comments, since acrobat reader
may not be easy for everyone to use. Sections and pages are in blue
text, with comments for the section following.
 
General:
In general a picture of the stack used by ZFS or a use case diagram of
what components/entities are where and what interfaces exist between
them would help put things in perspective in this document. (e.g. KMS,
Crypto unit, Data Set, Pool, etc.) 
 
Are there any kind of certification expectations for the implementation?
Since it is not mentioned, I assume not. Else, a reference would be
good.
 
page 1: section - Why are we doing this? 
Note, even if data is encrypted, traffic could be tampered with, which
should be mentioned. In-flight protection is not totally covered by just
encrypting the file data.

Q: Do both modes you target for phase 1 detect tampered customer data,
reordering, etc... in light of the above comment? What particular
threats are you trying to address? There is a little discussion of this
in the P1619.1 IEEE standard draft (annex) for those interested, I
believe. 

page 1: section - How are we doing this? 
Add: This encryption could be software implemented or utilizing hardware
acceleration.

Please clarify what kind of ports are being referred to. I believe it
should say "I/O ports".

A brief definition of the "pools" would be helpful or a reference to
an
architecture document.

page 2: section 2.2 Encryption Policy control
Q: Would it be better to say folder/directory or file level? in the
first paragraph.

Add to end of first sentence of second paragraph: and other information,
such as key usage information that might be necessary to enforce
encryption policies.

In second paragraph, I don''t understand why it is desirable to not
expose the algorithm mode to the administrator. Is it because of user
interface concerns? I don''t see any security problems with exposing the
information about the mode used. Please clarify what the concern is.

In second paragraph, I think it is a good idea to ensure extensibility
for future modes, algorithms, key lengths, etc. It says "we may choose
to...". I''d like to see it worded as a definite requirement. The
reference to GCM mode at first seemed like a contradiction, but I think
you are saying other modes can be added post phase 1.

page 2: section 2.3.1 Full Hardware

Might need to define the term "checksum" in the context of this
document. It is more than just adding up the byte values as described
here. You describe some hash fingerprints already. Might it also be a
CRC? 

page 3: section 2.3.2 Software only

It is a bad assumption to assume that hardware that accelerates
cryptographic algorithms also provides all KMServer services. It should
be assumed that the KMS and cryptographic unit that provides
acceleration could be different hardware. Please correct this incorrect
assumption.

page 3: section 2.3.3 Mixed mode

Add to end of first paragraph: or separate crypto accelerator

page 3: section 3.1 Key Management

Add discussion of how permission for access to the pool key is
controlled.

Also, in general the ideas of "master pool key", Key encrypting Key,
and
data encryption key, may not be used consistently in this document and
needs to be looked at for clarifications.

Seems like there should be multiple options for the storage of the Key
Encrypting Keys(KEK). Certainly the secure transport of the data
encryption keys needs to be discussed. 

Q1. How is the KEK determined?

Q2. Might compression acceleration also be useful for zfs? It isn''t
discussed.

page 3: section 3.2 Snapshots/Clones

It is not clear if the snapshot includes the wrapped key or not.

page 4: section 3.3 Encrypted ZVOL

Change "keys" to "data encryption keys" for clarity. You
have more than
one type of key being discussed in this document.

page 4: section 3.4 Zones and encrypted data sets

Adding a reference or definition to "non-global zones" would be
helpful.

page 4: section 4 Prerequisites

Title is mis-spelled.
 
page 4: section 4.1.2 Option relations
My suggestion is that you spec this as configuring a crypto suite to
configure the encryption and integrity (checksum) algorithms at one
time. Simplifies users life and allows him to tell an auditor what was
really used. Also contains the combinations that might be used together.
There are some RFC''s that seem to be going in that general direction to
clean up what algorithms are used in combination.

page 4: section 4.2 Cryptographic Framework

Was there a technical rationale for supporting only these modes in phase
1 over others that are candidates in the IEEE P1619 standards? If so
explain what the technical requirement was.

page 5: section 4.2 Cryptographic Framework

At the top of page five, is the first time the interaction with the user
is mentioned in the doc. How do the passphrase or token PIN relate, if
they do, to DEK and KEK? I presume the passphrase or token PIN are used
only in conjunction with the user interface (to what...?). Maybe you
need a separate section about user access. Again a picture might help
relate the reader to the use case you have in mind.

page 5: section 5.1.1 Dataset: encryption

Suggest you add "integrity" to a new "crypto suite"
property.

page 5: section 5.1.3 Dataset: key-mode

In second paragraph, "In this mode we..." Who? OpenSolaris? ZFS
software? Cryptographic Unit? Key Mgt Server?

In second paragraph, the document needs to call out the keywrapping
algorithm. How about AES keywrap as a reference? Or?

In third paragraph, suggest changing "we" to "the key management
server"
Do you assume the crypto unit also generates keys?  Why? It is not
always the case.

In third paragraph, add " or storing keys in a Key Management Server
(KMS)." to the end of the last sentence.

page 5: section 5.2 Pool: setkey

How is the master key established? First paragraph says it is used to
wrap the dataset keys.

page 6: section 5.5 Interaction...

This paragraph seems more like an application note about ZFS usage.
Didn''t seem to fit well with the rest of the doc, but valuable
information no doubt.

page 6: section 5.5 ZFS on disk blocks

What compression algorithms are supported by this design document?

Change: "The value of ZIO_CRYPT..." to "The default value of
ZIO_CRYPT..."

page 7: table at top of page

Per the other comments about using a crypto suite, the separate column
for checksum is confusing. A blank entry, maybe should say "N/A". 

Also typo in first row, "INERIT" should be "INHERIT"  I
think.

Should state explicitly what integrity (checksum) algorithmns are
required to be supported in phase 1 in the CCM rows. 

page 7: section 6.1 Secure deletion

See second paragraph. Somewhere in the doc it should clarify what master
key this is referring to. 

page 8:

typo: expiry?

If you persevered to the end of these comments. Congratulations! 

Hope these help,

Larry H

 
 
  _____  

From: zfs-crypto-discuss-bounces at opensolaris.org
[mailto:zfs-crypto-discuss-bounces at opensolaris.org] On Behalf Of Hofer,
Larry
Sent: Monday, July 16, 2007 3:20 PM
To: zfs-crypto-discuss at opensolaris.org
Cc: Hofer, Larry
Subject: [zfs-crypto-discuss] additional comments on design doc


Hello,
    I''ve attached a marked up design doc. Happy to discuss any or all. 
 
I did not go back and try to see if the comments have been addressed in
any of the e-mail threads, but I don''t think they all have been talked
about on this reflector since the document was posted.
 
Larry H
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-crypto-discuss/attachments/20070717/2522a978/attachment.html>

Larry.Hofer at Emulex.Com wrote:
> Hello,
> Here is the text file version of the same comments, since acrobat reader 
> may not be easy for everyone to use. Sections and pages are in blue 
> text, with comments for the section following.
>  
> General:
> In general a picture of the stack used by ZFS or a use case diagram of 
> what components/entities are where and what interfaces exist between 
> them would help put things in perspective in this document. (e.g. KMS, 
> Crypto unit, Data Set, Pool, etc.)
Okay I''ll see what I can do.
> Are there any kind of certification expectations for the implementation? 
> Since it is not mentioned, I assume not. Else, a reference would be good.
What kind of certification do you think is relevant ?

The crypto framework is currently undergoing a FIPS 140-2 certification 
of the framework and the software implementation.  Separately from that 
is a FIPS 140-2 certification of Sun''s CA-6000 card.

Solaris 10 has a Common Criteria CAPP,RBACPP,LSPP EAL4+ certification 
(LSSP is in progress the others have been granted already).

Certification unfortunately really applies to binary products rather 
than to the open source - partly because of the vast amounts of money 
required to do them they need corporate funding.
> page 1: section - Why are we doing this?
> Note, even if data is encrypted, traffic could be tampered with, which 
> should be mentioned. In-flight protection is not totally covered by just 
> encrypting the file data.
This project adds integrity protection as well as just encryption. 
I''ll
try and clarify this though.
> Q: Do both modes you target for phase 1 detect tampered customer data, 
> reordering, etc... in light of the above comment? What particular 
> threats are you trying to address? There is a little discussion of this 
> in the P1619.1 IEEE standard draft (annex) for those interested, I believe.
> 
> page 1: section - How are we doing this?
> 
> Add: This encryption could be software implemented or utilizing hardware 
> acceleration.
It is mentioned later.
> Please clarify what kind of ports are being referred to. I believe it 
> should say "I/O ports".
"Ports" in this context means a software port of ZFS to platforms
other
than OpenSolaris, as has already been done for FreeBSD and a port to FUSE.
> A brief definition of the "pools" would be helpful or a reference
to an
> architecture document.
The document does say it assumes the reader is already familiar with 
ZFS.  I''ll put in a reference.
> page 2: section 2.2 Encryption Policy control
> 
> Q: Would it be better to say folder/directory or file level? in the 
> first paragraph.
Yes since some systems do allow the policy to be set at the level of an 
  named file.
> Add to end of first sentence of second paragraph: and other information, 
> such as key usage information that might be necessary to enforce 
> encryption policies.
I''m not sure what you are asking for here since phase 1 of this project
has no key usage restrictions.
> In second paragraph, I don''t understand why it is desirable to not
> expose the algorithm mode to the administrator. Is it because of user 
> interface concerns? I don''t see any security problems with
exposing the
> information about the mode used. Please clarify what the concern is.
It is desirable because most system admins are not skilled in 
cryptography just like most cryptographers are not skilled at managing a 
data centre.  It isn''t a security issue but a UI one and the desire was
to not force admins to learn that aes-cbc and aes-ccm and aes-foo are 
different.  Since we are delivering both cbc and ccm modes in this phase 
I''ll just drop that statement.
> In second paragraph, I think it is a good idea to ensure extensibility 
> for future modes, algorithms, key lengths, etc. It says "we may choose
> to...". I''d like to see it worded as a definite requirement. 
Agreed since we are actually doing that now - I wrote that when we had 
planned to have only one mode in phase 1.

 > The
> reference to GCM mode at first seemed like a contradiction, but I think 
> you are saying other modes can be added post phase 1.
Correct other modes maybe added in later phases.
> page 2: section 2.3.1 Full Hardware
> 
> Might need to define the term "checksum" in the context of this 
> document. It is more than just adding up the byte values as described 
> here. You describe some hash fingerprints already. Might it also be a CRC?
The checksum definition here is the standard one for ZFS.  As is 
mentioned at the top of the document the reader is assumed to be 
familiar with ZFS.

The current ZFS implementation has: fletcher2 | fletcher 4 | sha256.
CRC is not an option.  This project adds hmac-sha256 as an additional
checksum type.
> page 3: section 2.3.2 Software only
> 
> It is a bad assumption to assume that hardware that accelerates 
> cryptographic algorithms also provides all KMServer services. It should 
> be assumed that the KMS and cryptographic unit that provides 
> acceleration could be different hardware. Please correct this incorrect 
> assumption.
I''ll remove the assumption because it has confused a number of people. 
This project is using the existing OpenSolaris cryptographic framework 
and it automatically deals with choosing wither to schedule jobs to 
hardware or software.  The crypto framework has load balancing and 
failover capabilities as well as an understanding that for a given 
algorithm there is a lower bound threshold of when it is useful to go to 
hardware from a pure single thread performance view.
> page 3: section 2.3.3 Mixed mode
> 
> Add to end of first paragraph: or separate crypto accelerator
I don''t see how that would make sense.
> page 3: section 3.1 Key Management
> 
> Add discussion of how permission for access to the pool key is controlled.
> 
> Also, in general the ideas of "master pool key", Key encrypting
Key, and
> data encryption key, may not be used consistently in this document and 
> needs to be looked at for clarifications.
Shall do.
> Seems like there should be multiple options for the storage of the Key 
> Encrypting Keys(KEK). Certainly the secure transport of the data 
> encryption keys needs to be discussed.
There will be, that wasn''t finalised before we started the review.  The
updated document will have this.
> Q1. How is the KEK determined?
> 
> Q2. Might compression acceleration also be useful for zfs? It
isn''t
> discussed.
It might but it isn''t this project.
> page 3: section 3.2 Snapshots/Clones
> 
> It is not clear if the snapshot includes the wrapped key or not.
It doesn''t.  The wrapped key is a property of the dataset and since 
snapshots are always encrypted with the same key as their parent there 
is no need for the snapshot to have a separate copy of the wrapped key. 
  I''ll try and make this clearer.
> page 4: section 3.3 Encrypted ZVOL
> 
> Change "keys" to "data encryption keys" for clarity.
You have more than
> one type of key being discussed in this document.
Agreed, but the ephemeral key mode is going to be dropped from this 
project since the general strategy for swapping with ZFS root filesystem 
is not going to be to use a ZVOL.  A separate project will deal with 
providing encrypted swap support.
> page 4: section 3.4 Zones and encrypted data sets
> 
> Adding a reference or definition to "non-global zones" would be
helpful.
I''ll add a reference.

> page 4: section 4.1.2 Option relations
> 
> My suggestion is that you spec this as configuring a crypto suite to 
> configure the encryption and integrity (checksum) algorithms at one 
> time. Simplifies users life and allows him to tell an auditor what was 
> really used. Also contains the combinations that might be used together. 
> There are some RFC''s that seem to be going in that general
direction to
> clean up what algorithms are used in combination.
I''ll look into that.

I think what you are suggesting is this:

current spec says:
	zfs create -o encryption=aes-128-cbc tank/home

The spec says that aes-128-cbc implies we force checksum=hmac-sha256.

I believe you are saying we should instead say something like:

	zfs create -o encryption=aes-128-cbc:hmac-sha256

Thats really just a UI difference.

Where it is different though is when using a CCM mode in this phase 
because there we allow the zfs admin to independently set the dataset 
checksum algorithm - we allow this because CCM has its own data auth tag 
that is stored alongside the data rather than being stored where zfs 
stores checksums normally.

> page 4: section 4.2 Cryptographic Framework
> 
> Was there a technical rationale for supporting only these modes in phase 
> 1 over others that are candidates in the IEEE P1619 standards? If so 
> explain what the technical requirement was.
The rationale is really one of resources more than anything else.  We 
have AES-CCM and AES-CBC in the crypto framework now we don''t yet have 
any of the other P1619 candidate modes.
> page 5: section 4.2 Cryptographic Framework
> 
> At the top of page five, is the first time the interaction with the 
> user is mentioned in the doc. How do the passphrase or token PIN relate, 
> if they do, to DEK and KEK? I presume the passphrase or token PIN are 
> used only in conjunction with the user interface (to what...?). Maybe 
> you need a separate section about user access. Again a picture might 
> help relate the reader to the use case you have in mind.
As above that whole thing needs to be added to the document.
> page 5: section 5.1.1 Dataset: encryption
> 
> Suggest you add "integrity" to a new "crypto suite"
property.
I disagree.  ZFS already provides a good checksum system and by adding 
hmac-sha256 as an option for that we provide integrity without needing 
an additional property or storing additional stuff.

I will, as above, however consider the UI and see if specifying a suite 
rather than separate encryption and checksum properties provides a 
better UI.
> page 5: section 5.1.3 Dataset: key-mode
> 
> In second paragraph, "In this mode we..." Who? OpenSolaris? ZFS 
> software? Cryptographic Unit? Key Mgt Server?
ZFS software asks the crypto framework to generate a random key.
I''ll clarify.
> In second paragraph, the document needs to call out the keywrapping 
> algorithm. How about AES keywrap as a reference? Or?
Agreed.
> In third paragraph, suggest changing "we" to "the key
management
> server"  Do you assume the crypto unit also generates keys?  Why? It
is
> not always the case.
> 
> In third paragraph, add " or storing keys in a Key Management Server 
> (KMS)." to the end of the last sentence.
The third paragraph will be going away as we are dropping ephemeral key 
support.
> page 5: section 5.2 Pool: setkey
> 
> How is the master key established? First paragraph says it is used to 
> wrap the dataset keys.
As above.
> page 6: section 5.5 Interaction...
> 
> This paragraph seems more like an application note about ZFS usage. 
> Didn''t seem to fit well with the rest of the doc, but valuable 
> information no doubt.
It is about the full OpenSolaris system impact of this project.
> page 6: section 5.5 ZFS on disk blocks
> 
> What compression algorithms are supported by this design document?
This project doesn''t add or change any compression support, it already 
exists in ZFS.
> Change: "The value of ZIO_CRYPT..." to "The default value of
ZIO_CRYPT..."
What I wrote is correct, however it does need to be clarified as it is 
not clear unless you understand the codebase.

What we are really saying here is if you specify encryption=on rather 
than selecting an algorithm then at this time we pick aes-128-cbc.  We 
need to also add a rationale for why that is the default we pick; to 
this design doc and the end user documentation.
> page 7: table at top of page
> 
> Per the other comments about using a crypto suite, the separate column 
> for checksum is confusing. A blank entry, maybe should say "N/A".
> 
> Also typo in first row, "INERIT" should be "INHERIT"  I
think.
> 
> Should state explicitly what integrity (checksum) algorithmns are 
> required to be supported in phase 1 in the CCM rows.
The intent of "any" is that if you select a CCM mode for encryption
they
you are able to select any of the currently supported checksum 
algorithms.  While I could list them explicitly that actually gives a 
different result because it implies only that set.
> page 7: section 6.1 Secure deletion
> 
> See second paragraph. Somewhere in the doc it should clarify what master 
> key this is referring to.
Agreed.
> page 8:
> 
> typo: expiry?
> 
> If you persevered to the end of these comments. Congratulations!
Thanks for your very valuable comments, and thanks for providing them in 
this form.

--
Darren J Moffat