Hi Stephan, On Fri, 8 Jan 2021 at 18:57, Stephan Mueller <smueller@xxxxxxxxxx> wrote: > > Am Freitag, dem 08.01.2021 um 17:38 +0000 schrieb Elena Petrova: > > 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. > 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... > 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. > 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 and "it's too late". 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". Cheers, Elena
