[External] : Re: FIPS compliance in OpenSSL v3.0

[Dr Paul Dale]

Changes to the FIPS provider are more problematic as they require review 
by the accreditation lab and, depending on the changes, potentially a 
revalidation.  The project's intention has always been to periodically 
update the validation to dot release versions and we are in the process 
of doing this at the moment.  The update will address the small number 
of known issues inside the FIPS boundary. Don't hold your breath 
waiting, the process is slow and none of the issues are critical as far 
as I'm aware.

The sqrt issue mentioned will be addressed as part of this 
revalidation.  However, it's rather tricky to trigger it in the FIPS 
provider.  The problem relates to loading malformed keys and this is 
generally done by the base or default providers before transferring them 
to the FIPS provider.  I.e. the problem will be encountered before the 
errant key material reaches the FIPS boundary.  With a fixed librypto, 
the errant key material never gets far enough to cause a problem for the 
FIPS provider.


Pauli


On 9/2/23 10:46, Thomas Dwyer III wrote:
> These instructions appear to suggest there are no CVEs within version 
> 3.0.0 of the FIPS provider itself but I'm having a hard time 
> evaluating this. Taking CVE-2022-0778 as an example and looking at the 
> commit history, I see that this particular CVE was fixed in 
> a466912611aa which modified a single file: crypto/bn/bn_sqrt.c. This 
> filename appears in providers/fips.module.sources. Does that mean this 
> particular CVE does in fact impact version 3.0.0 of the FIPS provider 
> or do I misunderstand what the FIPS provider actually contains?
>
>
> Thanks,
> Tom.III
>
>
> On 2/8/23 13:10, Dr Paul Dale wrote:
>> You need to do this:
>>
>> 1. Configure, build and install OpenSSL 3.0.0 as per the security 
>> policy.  This gives you a FIPS provider that is compliant.
>>
>> 2. Configure, build and install the later version of OpenSSL 
>> *without* the `enable-fips' option.    This gives you the security 
>> and bug fixes.
>>
>> 3. Run the later version of OpenSSL with the 3.0.0 FIPS provider.  
>> You now have FIPS compliant cryptographic algorithms and the fixes.
>>
>> The intention has always been to support different versions of the 
>> FIPS provider just working across different releases (both earlier 
>> and later).
>>
>>
>> As for additional options during configuration, in step 2 above, 
>> these pose no problem since it's not FIPS related.  In step 1 it 
>> might be problematic & I'd suggest talking to a FIPS lab or auditor 
>> about any specifics.  However, there really isn't much need to tweak 
>> the build in the step 1.
>>
>>
>> Pauli
>>
>>
>> On 9/2/23 06:58, Afshin Pir wrote:
>>>
>>> Hi
>>>
>>> Regarding FIPS compliance, I read following statement in your 
>>> README-FIPS.md:
>>>
>>> If you need a FIPS validated module then you must ONLY generate a 
>>> FIPS provider using OpenSSL versions that have valid FIPS 
>>> certificates. A FIPS certificate contains a link to a Security 
>>> Policy, and you MUST follow the instructions in the Security Policy 
>>> in order to be FIPS compliant.
>>>
>>> If I check security policy, I need to use 
>>> https://www.openssl.org/source/openssl-3.0.0.tar.gz and configure it 
>>> with ‘enable-fips’ option only. Now I have 2 questions: What does 
>>> happen if a security hole is seen on OpenSSL? If I build FIPS module 
>>> using newer source codes that resolve that security hole, my module 
>>> will not have FIPS compliance? My second question is if compiling 
>>> code with other options (like no-deprecated or no-engine) will also 
>>> break FIPS compliance or not. Any idea?
>>>
>>> Best Regards,
>>>
>>> Afshin
>>>
>>> ------------------------------------------------------------------------
>>> This email is confidential and may contain information subject to 
>>> legal privilege. If you are not the intended recipient please advise 
>>> us of our error by return e-mail then delete this email and any 
>>> attached files. You may not copy, disclose or use the contents in 
>>> any way. The views expressed in this email may not be those of 
>>> Gallagher Group Ltd or subsidiary companies thereof.
>>> ------------------------------------------------------------------------
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230209/ac438488/attachment.htm>