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]>