Re: [PATCH] crypto: testmgr - add NIAP FPT_TST_EXT.1 subset of tests

Am Dienstag, dem 09.02.2021 um 13:35 +0000 schrieb Elena Petrova:

Hi Stephan,

On Fri, 8 Jan 2021 at 18:57, Stephan Mueller [off-list ref] wrote:

quoted

Am Freitag, dem 08.01.2021 um 17:38 +0000 schrieb Elena Petrova:

quoted

NIAP FPT_TST_EXT.1 [1] specification requires testing of a small set of
cryptographic modules on boot for devices that need to be NIAP
compliant. This is also a requirement for FIPS CMVP 140-2/140-3
certification.

Currently testmgr adds significant boot time overhead when enabled; we
measured 3-5 seconds for Android.

I am not sure whether this is necessary. If you build the ciphers as
modules,
you can insmod them during boot time before general user space is made
available. Once you insmoded all needed KOs, you load tcrypt to invoke
them
which implies that they are verified. This approach allows user space to
determine which KOs are self-tested during boot.

We've asked our certification lab whether they'd approve the tcrypt
testing, but they say they are concerned that the test would run too
late and it won't exactly match the NIAP requirements.

Tcrypt does not do any testing, it simply allocates the ciphers to ensure that
the self tests defined in testmgr are executed.

If tcrypt is loaded as one of the first steps in user space boot, the self
tests are executed before any algo is put to use.

quoted

This is the approach all Linux validations took in the past.

If you could provide an example of some validation that folks from the
ecosystem did successfully with tcrypt, then I might be able to point
the lab to their CMVP certificate (like
 
https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/3753
),
and maybe that'd make them happy with Android using tcrypt...

Search for all RHEL/SLES/Ubuntu CMVP kernel validations.

The key is in the dracut component:

https://github.com/dracutdevs/dracut/tree/master/modules.d/01fips

quoted

Besides, for FIPS 140-3, it is now allowed to have "lazy" self testing
which
allows the self-tests to be executed before first use (just like what the
kernel testmgr already does).

Yeah, that's what I was intending to utilize in my patch: I just
reduced the number of crypto modules to which the self-tests should
apply, to avoid testing ones that aren't essential to certification.

What I mean is that with 140-3 the current kernel behavior of invoking the
testmgr during the first-time allocation of an algorithm is sufficient without
any changes to the current code.

quoted

Can you please help us understand why the mentioned approach is not
sufficient?

Well, as I mentioned above, the certification lab is concerned about
invoking tcrypt for testing because user-space controls it

Yes, user space controls it, but not the user. It is hard-wired into the boot
process.

 and "it's
too late".

Not sure how it can be too late if it is one of the first steps in the user
space boot.

 And the testmgr, when fully enabled, introduces a big
enough boot time increase for our Android team to shout at me angrily
:) So I decided to go with "testmgr but partial".

Check the dracut approach - there you have your selection ability.

Ciao
Stephan

Cheers,
Elena