fscrypt and FIPS

fscrypt and FIPS

[Jeff Layton]

Hi Eric,

I'm still working on the ceph+fscrypt patches (it's been slow going, but
I am making progress). Eventually RH would like to ship this as a
feature, but there is one potential snag that  -- a lot of our customers
need their boxes to be FIPS-enabled [1].

Most of the algorithms and implementations that fscrypt use are OK, but
HKDF is not approved outside of TLS 1.3. The quote from our lab folks
is:

"HKDF is not approved as a general-purpose KDF, but only for SP800-56C
rev2 compliant use. That means that HKDF is only to be used to derive a
key from a ECDH/DH or RSA-wrapped shared secret. This includes TLS 1.3."

Would you be amenable to allowing the KDF to be pluggable in some
fashion, like the filename and content encryption algorithms are? It
would be nice if we didn't have to disable this feature on FIPS-enabled
boxes.

[1]: https://www.nist.gov/itl/fips-general-information

Thanks!
-- 
Jeff Layton <jlayton@redhat.com>

Re: fscrypt and FIPS

[Eric Biggers]

On Wed, Feb 10, 2021 at 08:14:08AM -0500, Jeff Layton wrote:
> Hi Eric,
> 
> I'm still working on the ceph+fscrypt patches (it's been slow going, but
> I am making progress). Eventually RH would like to ship this as a
> feature, but there is one potential snag that  -- a lot of our customers
> need their boxes to be FIPS-enabled [1].
> 
> Most of the algorithms and implementations that fscrypt use are OK, but
> HKDF is not approved outside of TLS 1.3. The quote from our lab folks
> is:
> 
> "HKDF is not approved as a general-purpose KDF, but only for SP800-56C
> rev2 compliant use. That means that HKDF is only to be used to derive a
> key from a ECDH/DH or RSA-wrapped shared secret. This includes TLS 1.3."
> 
> Would you be amenable to allowing the KDF to be pluggable in some
> fashion, like the filename and content encryption algorithms are? It
> would be nice if we didn't have to disable this feature on FIPS-enabled
> boxes.
> 
> [1]: https://www.nist.gov/itl/fips-general-information
> 
> Thanks!
> -- 
> Jeff Layton <jlayton@redhat.com>

Can you elaborate on why you think that HKDF isn't FIPS approved?  It's been
recommended by NIST 800-56C since 2011, and almost any cryptographic application
developed within the last 10 years is likely to be using HKDF, if it needs a
non-passphrase based KDF.

In fact one of the reasons for switching from the weird AES-ECB-based KDF used
in v1 encryption policies to HKDF-SHA512 is that HKDF is much more standard.

Are you sure you're looking at the latest version of FIPS?

And if HKDF isn't approved, what *is* approved, exactly?

As far as supporting a new KDF if it were necessary, one of the reserved fields
in fscrypt_add_key_arg, fscrypt_policy_v2, fscrypt_context_v2, and
fscrypt_provisioning_key_payload could be used to specify the KDF.  This would
the first time someone has done so, so there would also be work required to add
a '--kdf' parameter to the userspace tools, and make the kernel keep track of
the keys for each KDF version separately.  Plus maybe some other things too.

I did figure that a new KDF might have to be supported eventually, but not to
replace the HKDF construction (which is provably secure), but rather if someone
wants to use something other than SHA-512 (which isn't provably secure).  I'm
not too enthusiastic about adding another KDF that uses the same underlying hash
function, as there would be no technical reason for this.

Note that the fscrypt userspace tool (https://github.com/google/fscrypt) also
uses HKDF for a key derivation step in userspace, separately from the kernel.
I suppose you'd want to change that too?

- Eric

Re: fscrypt and FIPS

[Jeff Layton]

On Wed, 2021-02-10 at 09:49 -0800, Eric Biggers wrote:
> On Wed, Feb 10, 2021 at 08:14:08AM -0500, Jeff Layton wrote:
> > Hi Eric,
> > 
> > I'm still working on the ceph+fscrypt patches (it's been slow going, but
> > I am making progress). Eventually RH would like to ship this as a
> > feature, but there is one potential snag that  -- a lot of our customers
> > need their boxes to be FIPS-enabled [1].
> > 
> > Most of the algorithms and implementations that fscrypt use are OK, but
> > HKDF is not approved outside of TLS 1.3. The quote from our lab folks
> > is:
> > 
> > "HKDF is not approved as a general-purpose KDF, but only for SP800-56C
> > rev2 compliant use. That means that HKDF is only to be used to derive a
> > key from a ECDH/DH or RSA-wrapped shared secret. This includes TLS 1.3."
> > 
> > Would you be amenable to allowing the KDF to be pluggable in some
> > fashion, like the filename and content encryption algorithms are? It
> > would be nice if we didn't have to disable this feature on FIPS-enabled
> > boxes.
> > 
> > [1]: https://www.nist.gov/itl/fips-general-information
> > 
> > Thanks!
> > -- 
> > Jeff Layton <jlayton@redhat.com>
> 
> Can you elaborate on why you think that HKDF isn't FIPS approved?  It's been
> recommended by NIST 800-56C since 2011, and almost any cryptographic application
> developed within the last 10 years is likely to be using HKDF, if it needs a
> non-passphrase based KDF.
> 
> In fact one of the reasons for switching from the weird AES-ECB-based KDF used
> in v1 encryption policies to HKDF-SHA512 is that HKDF is much more standard.
> 
> Are you sure you're looking at the latest version of FIPS?
> 
> And if HKDF isn't approved, what *is* approved, exactly?
> 
> As far as supporting a new KDF if it were necessary, one of the reserved fields
> in fscrypt_add_key_arg, fscrypt_policy_v2, fscrypt_context_v2, and
> fscrypt_provisioning_key_payload could be used to specify the KDF.  This would
> the first time someone has done so, so there would also be work required to add
> a '--kdf' parameter to the userspace tools, and make the kernel keep track of
> the keys for each KDF version separately.  Plus maybe some other things too.
> 
> I did figure that a new KDF might have to be supported eventually, but not to
> replace the HKDF construction (which is provably secure), but rather if someone
> wants to use something other than SHA-512 (which isn't provably secure).  I'm
> not too enthusiastic about adding another KDF that uses the same underlying hash
> function, as there would be no technical reason for this.
> 
> Note that the fscrypt userspace tool (https://github.com/google/fscrypt) also
> uses HKDF for a key derivation step in userspace, separately from the kernel.
> I suppose you'd want to change that too?
> 
> 

Bah, I meant to cc Simo on this since he's the one who brought it up. I
know just enough to be dangerous. 

Simo, can you answer Eric's questions, or loop in someone who can?

Thanks,
-- 
Jeff Layton <jlayton@redhat.com>

Re: fscrypt and FIPS

[Thibaud Ecarot]

Hi folks,

HKDF is widely used in various HSM so this is necessarily compliant
with FIPS 140-3 or 140-2. I have in mind Thales Luna HSM. I am curious
why this statement was made on your side.

Thanks Jeff.

Thibaud


Le mer. 10 févr. 2021, à 14 h 30, Jeff Layton <jlayton@redhat.com> a écrit :
>
> On Wed, 2021-02-10 at 09:49 -0800, Eric Biggers wrote:
> > On Wed, Feb 10, 2021 at 08:14:08AM -0500, Jeff Layton wrote:
> > > Hi Eric,
> > >
> > > I'm still working on the ceph+fscrypt patches (it's been slow going, but
> > > I am making progress). Eventually RH would like to ship this as a
> > > feature, but there is one potential snag that  -- a lot of our customers
> > > need their boxes to be FIPS-enabled [1].
> > >
> > > Most of the algorithms and implementations that fscrypt use are OK, but
> > > HKDF is not approved outside of TLS 1.3. The quote from our lab folks
> > > is:
> > >
> > > "HKDF is not approved as a general-purpose KDF, but only for SP800-56C
> > > rev2 compliant use. That means that HKDF is only to be used to derive a
> > > key from a ECDH/DH or RSA-wrapped shared secret. This includes TLS 1.3."
> > >
> > > Would you be amenable to allowing the KDF to be pluggable in some
> > > fashion, like the filename and content encryption algorithms are? It
> > > would be nice if we didn't have to disable this feature on FIPS-enabled
> > > boxes.
> > >
> > > [1]: https://www.nist.gov/itl/fips-general-information
> > >
> > > Thanks!
> > > --
> > > Jeff Layton <jlayton@redhat.com>
> >
> > Can you elaborate on why you think that HKDF isn't FIPS approved?  It's been
> > recommended by NIST 800-56C since 2011, and almost any cryptographic application
> > developed within the last 10 years is likely to be using HKDF, if it needs a
> > non-passphrase based KDF.
> >
> > In fact one of the reasons for switching from the weird AES-ECB-based KDF used
> > in v1 encryption policies to HKDF-SHA512 is that HKDF is much more standard.
> >
> > Are you sure you're looking at the latest version of FIPS?
> >
> > And if HKDF isn't approved, what *is* approved, exactly?
> >
> > As far as supporting a new KDF if it were necessary, one of the reserved fields
> > in fscrypt_add_key_arg, fscrypt_policy_v2, fscrypt_context_v2, and
> > fscrypt_provisioning_key_payload could be used to specify the KDF.  This would
> > the first time someone has done so, so there would also be work required to add
> > a '--kdf' parameter to the userspace tools, and make the kernel keep track of
> > the keys for each KDF version separately.  Plus maybe some other things too.
> >
> > I did figure that a new KDF might have to be supported eventually, but not to
> > replace the HKDF construction (which is provably secure), but rather if someone
> > wants to use something other than SHA-512 (which isn't provably secure).  I'm
> > not too enthusiastic about adding another KDF that uses the same underlying hash
> > function, as there would be no technical reason for this.
> >
> > Note that the fscrypt userspace tool (https://github.com/google/fscrypt) also
> > uses HKDF for a key derivation step in userspace, separately from the kernel.
> > I suppose you'd want to change that too?
> >
> >
>
> Bah, I meant to cc Simo on this since he's the one who brought it up. I
> know just enough to be dangerous.
>
> Simo, can you answer Eric's questions, or loop in someone who can?
>
> Thanks,
> --
> Jeff Layton <jlayton@redhat.com>
>


-- 
Thibaud ECAROT

Re: fscrypt and FIPS

[Simo Sorce]

Very quickly,
our current assessment is that HKDF is approved to be used only within
the protocols explicitly approved in FIPS 140-3 IG and 800-135r1, which
include TLS 1.3 but not generally.

I will come back with more info an pointers asap.

Simo.

On Wed, 2021-02-10 at 15:07 -0500, Thibaud Ecarot wrote:
> Hi folks,
> 
> HKDF is widely used in various HSM so this is necessarily compliant
> with FIPS 140-3 or 140-2. I have in mind Thales Luna HSM. I am curious
> why this statement was made on your side.
> 
> Thanks Jeff.
> 
> Thibaud
> 
> 
> Le mer. 10 févr. 2021, à 14 h 30, Jeff Layton <jlayton@redhat.com> a écrit :
> > On Wed, 2021-02-10 at 09:49 -0800, Eric Biggers wrote:
> > > On Wed, Feb 10, 2021 at 08:14:08AM -0500, Jeff Layton wrote:
> > > > Hi Eric,
> > > > 
> > > > I'm still working on the ceph+fscrypt patches (it's been slow going, but
> > > > I am making progress). Eventually RH would like to ship this as a
> > > > feature, but there is one potential snag that  -- a lot of our customers
> > > > need their boxes to be FIPS-enabled [1].
> > > > 
> > > > Most of the algorithms and implementations that fscrypt use are OK, but
> > > > HKDF is not approved outside of TLS 1.3. The quote from our lab folks
> > > > is:
> > > > 
> > > > "HKDF is not approved as a general-purpose KDF, but only for SP800-56C
> > > > rev2 compliant use. That means that HKDF is only to be used to derive a
> > > > key from a ECDH/DH or RSA-wrapped shared secret. This includes TLS 1.3."
> > > > 
> > > > Would you be amenable to allowing the KDF to be pluggable in some
> > > > fashion, like the filename and content encryption algorithms are? It
> > > > would be nice if we didn't have to disable this feature on FIPS-enabled
> > > > boxes.
> > > > 
> > > > [1]: https://www.nist.gov/itl/fips-general-information
> > > > 
> > > > Thanks!
> > > > --
> > > > Jeff Layton <jlayton@redhat.com>
> > > 
> > > Can you elaborate on why you think that HKDF isn't FIPS approved?  It's been
> > > recommended by NIST 800-56C since 2011, and almost any cryptographic application
> > > developed within the last 10 years is likely to be using HKDF, if it needs a
> > > non-passphrase based KDF.
> > > 
> > > In fact one of the reasons for switching from the weird AES-ECB-based KDF used
> > > in v1 encryption policies to HKDF-SHA512 is that HKDF is much more standard.
> > > 
> > > Are you sure you're looking at the latest version of FIPS?
> > > 
> > > And if HKDF isn't approved, what *is* approved, exactly?
> > > 
> > > As far as supporting a new KDF if it were necessary, one of the reserved fields
> > > in fscrypt_add_key_arg, fscrypt_policy_v2, fscrypt_context_v2, and
> > > fscrypt_provisioning_key_payload could be used to specify the KDF.  This would
> > > the first time someone has done so, so there would also be work required to add
> > > a '--kdf' parameter to the userspace tools, and make the kernel keep track of
> > > the keys for each KDF version separately.  Plus maybe some other things too.
> > > 
> > > I did figure that a new KDF might have to be supported eventually, but not to
> > > replace the HKDF construction (which is provably secure), but rather if someone
> > > wants to use something other than SHA-512 (which isn't provably secure).  I'm
> > > not too enthusiastic about adding another KDF that uses the same underlying hash
> > > function, as there would be no technical reason for this.
> > > 
> > > Note that the fscrypt userspace tool (https://github.com/google/fscrypt) also
> > > uses HKDF for a key derivation step in userspace, separately from the kernel.
> > > I suppose you'd want to change that too?
> > > 
> > > 
> > 
> > Bah, I meant to cc Simo on this since he's the one who brought it up. I
> > know just enough to be dangerous.
> > 
> > Simo, can you answer Eric's questions, or loop in someone who can?
> > 
> > Thanks,
> > --
> > Jeff Layton <jlayton@redhat.com>
> > 
> 
> 

Re: fscrypt and FIPS

[Simo Sorce]

Some more info, sorry for the delay.

Currently, as epxlained eralier, the HKDF is approved only in specific
cases (from SP.800-56C rev 2), which is why I asked Jeff to inquire if
KDF agility was possible for fscrypt.

That said, we are also trying to get NIST to approve HKDF for use in
SP800-133 covered scenarios (Symmetric Keys Derived from Pre-Existing
Key), which is the case applicable to fscrypt (afaict).

SP.800-133 currently only allows KDFs as defined in SP.800-108, but
there is hope that SP.800-56C rev 2 KDFs can be alloed also, after all
they are already allowed for key-agreement schemes.

Hope this clears a bit why we inquired, it is just in case, for
whatever reason, NIST decided not to approve or delays a decision; to
be clear, there is nothing wrong in HKDF itself that we know of.

HTH,
Simo.

On Wed, 2021-02-10 at 15:12 -0500, Simo Sorce wrote:
> Very quickly,
> our current assessment is that HKDF is approved to be used only within
> the protocols explicitly approved in FIPS 140-3 IG and 800-135r1, which
> include TLS 1.3 but not generally.
> 
> I will come back with more info an pointers asap.
> 
> Simo.
> 
> On Wed, 2021-02-10 at 15:07 -0500, Thibaud Ecarot wrote:
> > Hi folks,
> > 
> > HKDF is widely used in various HSM so this is necessarily compliant
> > with FIPS 140-3 or 140-2. I have in mind Thales Luna HSM. I am curious
> > why this statement was made on your side.
> > 
> > Thanks Jeff.
> > 
> > Thibaud
> > 
> > 
> > Le mer. 10 févr. 2021, à 14 h 30, Jeff Layton <jlayton@redhat.com> a écrit :
> > > On Wed, 2021-02-10 at 09:49 -0800, Eric Biggers wrote:
> > > > On Wed, Feb 10, 2021 at 08:14:08AM -0500, Jeff Layton wrote:
> > > > > Hi Eric,
> > > > > 
> > > > > I'm still working on the ceph+fscrypt patches (it's been slow going, but
> > > > > I am making progress). Eventually RH would like to ship this as a
> > > > > feature, but there is one potential snag that  -- a lot of our customers
> > > > > need their boxes to be FIPS-enabled [1].
> > > > > 
> > > > > Most of the algorithms and implementations that fscrypt use are OK, but
> > > > > HKDF is not approved outside of TLS 1.3. The quote from our lab folks
> > > > > is:
> > > > > 
> > > > > "HKDF is not approved as a general-purpose KDF, but only for SP800-56C
> > > > > rev2 compliant use. That means that HKDF is only to be used to derive a
> > > > > key from a ECDH/DH or RSA-wrapped shared secret. This includes TLS 1.3."
> > > > > 
> > > > > Would you be amenable to allowing the KDF to be pluggable in some
> > > > > fashion, like the filename and content encryption algorithms are? It
> > > > > would be nice if we didn't have to disable this feature on FIPS-enabled
> > > > > boxes.
> > > > > 
> > > > > [1]: https://www.nist.gov/itl/fips-general-information
> > > > > 
> > > > > Thanks!
> > > > > --
> > > > > Jeff Layton <jlayton@redhat.com>
> > > > 
> > > > Can you elaborate on why you think that HKDF isn't FIPS approved?  It's been
> > > > recommended by NIST 800-56C since 2011, and almost any cryptographic application
> > > > developed within the last 10 years is likely to be using HKDF, if it needs a
> > > > non-passphrase based KDF.
> > > > 
> > > > In fact one of the reasons for switching from the weird AES-ECB-based KDF used
> > > > in v1 encryption policies to HKDF-SHA512 is that HKDF is much more standard.
> > > > 
> > > > Are you sure you're looking at the latest version of FIPS?
> > > > 
> > > > And if HKDF isn't approved, what *is* approved, exactly?
> > > > 
> > > > As far as supporting a new KDF if it were necessary, one of the reserved fields
> > > > in fscrypt_add_key_arg, fscrypt_policy_v2, fscrypt_context_v2, and
> > > > fscrypt_provisioning_key_payload could be used to specify the KDF.  This would
> > > > the first time someone has done so, so there would also be work required to add
> > > > a '--kdf' parameter to the userspace tools, and make the kernel keep track of
> > > > the keys for each KDF version separately.  Plus maybe some other things too.
> > > > 
> > > > I did figure that a new KDF might have to be supported eventually, but not to
> > > > replace the HKDF construction (which is provably secure), but rather if someone
> > > > wants to use something other than SHA-512 (which isn't provably secure).  I'm
> > > > not too enthusiastic about adding another KDF that uses the same underlying hash
> > > > function, as there would be no technical reason for this.
> > > > 
> > > > Note that the fscrypt userspace tool (https://github.com/google/fscrypt) also
> > > > uses HKDF for a key derivation step in userspace, separately from the kernel.
> > > > I suppose you'd want to change that too?
> > > > 
> > > > 
> > > 
> > > Bah, I meant to cc Simo on this since he's the one who brought it up. I
> > > know just enough to be dangerous.
> > > 
> > > Simo, can you answer Eric's questions, or loop in someone who can?
> > > 
> > > Thanks,
> > > --
> > > Jeff Layton <jlayton@redhat.com>
> > > 

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

Re: fscrypt and FIPS

[Eric Biggers]

On Tue, Feb 16, 2021 at 12:47:05PM -0500, Simo Sorce wrote:
> Some more info, sorry for the delay.
> 
> Currently, as epxlained eralier, the HKDF is approved only in specific
> cases (from SP.800-56C rev 2), which is why I asked Jeff to inquire if
> KDF agility was possible for fscrypt.
> 
> That said, we are also trying to get NIST to approve HKDF for use in
> SP800-133 covered scenarios (Symmetric Keys Derived from Pre-Existing
> Key), which is the case applicable to fscrypt (afaict).
> 
> SP.800-133 currently only allows KDFs as defined in SP.800-108, but
> there is hope that SP.800-56C rev 2 KDFs can be alloed also, after all
> they are already allowed for key-agreement schemes.
> 
> Hope this clears a bit why we inquired, it is just in case, for
> whatever reason, NIST decided not to approve or delays a decision; to
> be clear, there is nothing wrong in HKDF itself that we know of.
> 

Just getting HKDF properly approved seems like a much better approach than doing
a lot of work for nothing.  Not just for fscrypt but also for everything else
using HKDF.

- Eric

Re: fscrypt and FIPS

[Simo Sorce]

On Tue, 2021-02-16 at 11:04 -0800, Eric Biggers wrote:
> On Tue, Feb 16, 2021 at 12:47:05PM -0500, Simo Sorce wrote:
> > Some more info, sorry for the delay.
> > 
> > Currently, as epxlained eralier, the HKDF is approved only in specific
> > cases (from SP.800-56C rev 2), which is why I asked Jeff to inquire if
> > KDF agility was possible for fscrypt.
> > 
> > That said, we are also trying to get NIST to approve HKDF for use in
> > SP800-133 covered scenarios (Symmetric Keys Derived from Pre-Existing
> > Key), which is the case applicable to fscrypt (afaict).
> > 
> > SP.800-133 currently only allows KDFs as defined in SP.800-108, but
> > there is hope that SP.800-56C rev 2 KDFs can be alloed also, after all
> > they are already allowed for key-agreement schemes.
> > 
> > Hope this clears a bit why we inquired, it is just in case, for
> > whatever reason, NIST decided not to approve or delays a decision; to
> > be clear, there is nothing wrong in HKDF itself that we know of.
> > 
> 
> Just getting HKDF properly approved seems like a much better approach than doing
> a lot of work for nothing.  Not just for fscrypt but also for everything else
> using HKDF.

Yes, this would be the ideal outcome!
But I have to figure out the "what if" too ..

> - Eric
> 

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc