Re: mutual authentication fails when FIPS enabled
Douglas E Engert <[email protected]> Wed, 3 Feb 2021 17:34:12 -0600
| Newsgroups | gmane.comp.encryption.opensc.devel |
|---|---|
| Message-ID | <[email protected]> |
I understand that this is not an easy problem to solve, given the complexity of libp11, OpenSSL with FIPS which is currently using 1.0.2. I like the suggestion of Christian Heimes. I have been looking at that, but have not got far. On 2/3/2021 12:17 PM, Anderson Sasaki wrote: > > ----- Original Message ----- >> From: "Douglas E Engert" <[email protected]> >> To: [email protected] >> Sent: Tuesday, February 2, 2021 2:48:45 PM >> Subject: Re: [Opensc-devel] mutual authentication fails when FIPS enabled >> >> The point of using a smartcard is the crypto operations are done on the smart >> card, token >> or other hardware like a HSM, or TPS. The point of FIPS is the software and >> hardware has >> been approved and tested to do appropriate crypto operations. >> >> The "fix" to just set RSA_FLAG_FIPS_METHOD is not a fix, it is lie. It in >> effect is saying >> libp11 take the responsibility of saying the PKCS11 modules and the smart >> card, tokens >> or other hardware are FIPS complaint. >> >> The problem today, from the PKCS#11 standpoint, there is no way to prove the >> PKCS#11 modules, >> and hardware meet the FIPS standards. Some PKCS#11 modules are software only, >> designed they can run the cloud and with better performance. Some smart cards >> have applets >> that have never bee approved. (Note: The RedHat comments in the bug fix say >> it is not a proper >> fix.) > > Hello, I am the Red Hat developer who introduced the "fix" there. > > The problem is that the engine don't have a way to ask the module if it is an > approved module or not (at least not yet). > > So the "fix" is basically making the engine to tell OpenSSL that the crypto > operations are being performed in an approved module regardless of the module > being used. > > This makes the previous a lie when the module is not approved. That is why it > is not a proper fix, but a workaround. > > In my understanding, this is transferring the responsibility of checking if > the module is indeed an approved module to the user. > > Ideally, the engine would have a way to be configured so that the user can > explicitly say "I know what I'm doing and I verified the module is approved". > >> >> You as the application developer have a choice, as to what version of OpenSSL >> you use. As >> Petr said, you can split the operations up, so the engine with pkcs11 is used >> with a non >> FIPS mode OpenSSL, and FIPS mode for the rest. Or you can use non-FIPS >> OpenSSL. Or modify >> the code like RedHat did. You also have a choice as to what PKCS11 modules >> and hardware >> you are using. >> >> From an OpenSC developer, I see this is a problem, but would not want to see >> the "fix" >> in the code as it is a lie. But it might be possible to add code that would >> set that flag >> Maybe via env variable? This would let the application developer decide if >> they want to take responsibility. > > For me, this is the closest to a proper fix that is possible to be implemented > for now. > > For the engine, I personally like the suggestion given by Christian Heimes which > is to add a CTRL command to set the flag > (see https://bugzilla.redhat.com/show_bug.cgi?id=1827535#c1). > > What do you think? > > Best regards, > Anderson Sasaki > > . > -- Douglas E. Engert <[email protected]>