[RFC] revamp fips_allowed flag

[RFC] revamp fips_allowed flag

[Stephan Mueller]

Hi Herbert,

The fips_allowed flag in testmgr.c shall prevent the use of "non-approved" 
ciphers in FIPS mode.

With the current code, the fips_allowed flag is bound to a name a specific 
cipher is referenced with. With the advent of more complex cipher string names 
that can be used (for example, consider names like 
"seqiv(rfc4106(gcm_base(ctr-aes-s390,ghash-generic)))", the authenc ciphers 
with the two components or even the recently added pkcspad1 algorithm), it 
seems that the approach in testmgr.c reached its limits. Lately more and more 
entries in the alg_test_descs array were added purely to have the fips_allowed 
flag set.

Wouldn't it be more prudent to move that flag into the crypto_alg and 
crypto_template data structures so that the flag is checked during the 
crypto_register_* functions? I.e. if the flag is not set and the FIPS mode is 
enabled, the cipher is simply not registered?

With that, suggestion, the fips_allowed flag is now decoupled from the cipher 
name. Complex cipher strings would now not be falsely treated as non-approved 
ciphers any more.

Ciao
Stephan
-- 
atsec information security GmbH, Steinstraße 70, 81667 München, Germany
P: +49 89 442 49 830 - F: +49 89 442 49 831
M: +49 172 216 55 78 - HRB: 129439 (Amtsgericht München)
US: +1 949 545 4096
GF: Salvatore la Pietra, Staffan Persson
atsec it security news blog - atsec-information-security.blogspot.com

Re: [RFC] revamp fips_allowed flag

[Herbert Xu]

On Thu, Sep 15, 2016 at 07:35:43AM +0200, Stephan Mueller wrote:
>
> Wouldn't it be more prudent to move that flag into the crypto_alg and 
> crypto_template data structures so that the flag is checked during the 
> crypto_register_* functions? I.e. if the flag is not set and the FIPS mode is 
> enabled, the cipher is simply not registered?

The problem with that is then if you have 10 implementations of a
given algorithm you'd have to change 10 places to modify its FIPS
status.

Where's the pain point here? For cases like seqiv where you want to
say if X is FIPS-allowed then so is seqiv(X) we can certainly add
some code to testmgr to cater for that instead of listing them
individually.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [RFC] revamp fips_allowed flag

[Stephan Mueller]

Am Donnerstag, 15. September 2016, 13:58:08 CEST schrieb Herbert Xu:

Hi Herbert,

> Where's the pain point here? For cases like seqiv where you want to
> say if X is FIPS-allowed then so is seqiv(X) we can certainly add
> some code to testmgr to cater for that instead of listing them
> individually.

Where shall we draw the line here? Shall that be only for authenc, or seqiv? 
Or shall we also consider rfc4106 too, knowing that there are implementations 
which provide a full rfc4106 GCM combo (x86 for example). What about the 
current pkcspad1 template where we could expect that there may be entire HW 
implementations with that?

Ciao
Stephan

Re: [RFC] revamp fips_allowed flag

[Herbert Xu]

On Thu, Sep 15, 2016 at 08:23:05AM +0200, Stephan Mueller wrote:
> 
> Where shall we draw the line here? Shall that be only for authenc, or seqiv? 
> Or shall we also consider rfc4106 too, knowing that there are implementations 
> which provide a full rfc4106 GCM combo (x86 for example). What about the 
> current pkcspad1 template where we could expect that there may be entire HW 
> implementations with that?

That's something that only you can tell us :)

For such templates we could move that info into the generic
template implementation code and have them declare themselves
as such that for any X if X is FIPS allowed then so is T(X).

This info can then be used in testmgr.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [RFC] revamp fips_allowed flag

[Stephan Mueller]

Am Donnerstag, 15. September 2016, 14:26:29 CEST schrieb Herbert Xu:

Hi Herbert,

> On Thu, Sep 15, 2016 at 08:23:05AM +0200, Stephan Mueller wrote:
> > Where shall we draw the line here? Shall that be only for authenc, or
> > seqiv? Or shall we also consider rfc4106 too, knowing that there are
> > implementations which provide a full rfc4106 GCM combo (x86 for example).
> > What about the current pkcspad1 template where we could expect that there
> > may be entire HW implementations with that?
> 
> That's something that only you can tell us :)

Well, as a baseline we can say  that:

- with the exception of a few block chaining modes (e.g. xcbc, pcbc, lrw) all 
templates are allowed in FIPS mode

- almost all "non-approved" ciphers (i.e those that should not have a 
fips_allowed flag) are due to the raw base cipher (i.e. only SHA1/2, AES and 
TDES is allowed)

- all compression algos are allowed
> 
> For such templates we could move that info into the generic
> template implementation code and have them declare themselves
> as such that for any X if X is FIPS allowed then so is T(X).
> 
> This info can then be used in testmgr.

I can see that, but I do not believe it makes our life in the testmgr easier. 
The reason is that in a lot of cases, the template parts (read: block chaining 
modes) are moved into implementations. The most notable examples are the x86 
Intel and the S390 CPACF implementations. For those, the template handling 
code is not triggered and thus we still would need testmgr entries with the 
block chaining modes.

Considering that we now have RSA in the kernel and that we could expect RSA 
implementations in hardware (in fact, we already have them), there is another 
complication: FIPS only allows RSA according to FIPS 186-4 and not according 
to FIPS 186-2 (ok, the main difference is in key gen, which we do not have). 
What I want to say here is that with the more complex style ciphers, it may 
very well be possible that only the respective implementation knows whether it 
is FIPS compliant.

Thus, I am still thinking that moving the fips_allowed flag into the structs 
that are evaluated during register time is more helpful. I definitely see that 
this would imply that all, say, AES implementations need that flag. But IMHO 
it is a much cleaner solution, because if the register is rejected, the cipher 
does not show up in /proc/crypto and everybody knows that a particular cipher 
is not in use.

My particular example is that in one test with FIPS mode enabled, 
seqiv(rfc4106(gcm-base(...))) was successfully loaded and marked as selftest 
passed in /proc/crypto. Yet, an allocation of the test failed with ENOENT. 
Rebooting the system without FIPS mode allowed me to allocate the cipher. As 
there is no test for this particular cipher name in testmgr, I highly suspect 
that the allocation code did not find it because somehow there was no test. In 
any case, it is definitely not clear why that particular cipher name cannot be 
allocated in FIPS mode given the entries in /proc/crypto.

Ciao
Stephan

Re: [RFC] revamp fips_allowed flag

[Herbert Xu]

On Fri, Sep 16, 2016 at 07:42:13AM +0200, Stephan Mueller wrote:
>
> > For such templates we could move that info into the generic
> > template implementation code and have them declare themselves
> > as such that for any X if X is FIPS allowed then so is T(X).
> > 
> > This info can then be used in testmgr.
> 
> I can see that, but I do not believe it makes our life in the testmgr easier. 
> The reason is that in a lot of cases, the template parts (read: block chaining 
> modes) are moved into implementations. The most notable examples are the x86 
> Intel and the S390 CPACF implementations. For those, the template handling 
> code is not triggered and thus we still would need testmgr entries with the 
> block chaining modes.

That's not what I meant.  The template is only responsible for
providing that info to testmgr.  The actual rule will then apply
to any cra_name which matches it.  That is, if template T says
that it is OK under FIPS, then every algorithm of type T(X) will
be allowed if X is allowed.

> Considering that we now have RSA in the kernel and that we could expect RSA 
> implementations in hardware (in fact, we already have them), there is another 
> complication: FIPS only allows RSA according to FIPS 186-4 and not according 
> to FIPS 186-2 (ok, the main difference is in key gen, which we do not have). 
> What I want to say here is that with the more complex style ciphers, it may 
> very well be possible that only the respective implementation knows whether it 
> is FIPS compliant.

Please give a concrete example.

> Thus, I am still thinking that moving the fips_allowed flag into the structs 
> that are evaluated during register time is more helpful. I definitely see that 
> this would imply that all, say, AES implementations need that flag. But IMHO 
> it is a much cleaner solution, because if the register is rejected, the cipher 
> does not show up in /proc/crypto and everybody knows that a particular cipher 
> is not in use.

That's crazy.  For AES we already have dozens of implementations,
think about the amount of churn that will occur when one AES
implementation is obsoleted by FIPS.

> My particular example is that in one test with FIPS mode enabled, 
> seqiv(rfc4106(gcm-base(...))) was successfully loaded and marked as selftest 
> passed in /proc/crypto. Yet, an allocation of the test failed with ENOENT. 
> Rebooting the system without FIPS mode allowed me to allocate the cipher. As 
> there is no test for this particular cipher name in testmgr, I highly suspect 
> that the allocation code did not find it because somehow there was no test. In 
> any case, it is definitely not clear why that particular cipher name cannot be 
> allocated in FIPS mode given the entries in /proc/crypto.

Sounds like our testmgr dealing with FIPS is buggy.  It probably
shouldn't mark it as passed.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt