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
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 <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
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
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 <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
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
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 <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt