> From the OpenSSL FIPS Security Policy chapter 4, it mentioned there are a
> number of non-FIPS approved algorithms/ services which are still
> implemented by the FIPS canister modules (e.g. RSA, DSA, DRDB, ECDSA etc).
>
> Just wondering why these algorithms are still implemented by FIPS Canister.
>
> The concern is, if these algorithms could still be used under FIPS mode,
> there is risk that the applications which use the FIPS canister modules may
> become non-FIPS compliant if these algorithms are used by mistake.
You are correct. It is possible for an application to use the OpenSSL FOM in a non-approved way by calling a non-approved service listed in Table 4c of the OpenSSL FOM Security Policy. I'm sure it was easier for the OpenSSL team to make documentation changes (rather than making coding changes and performing additional FIPS testing) to maintain the validity of the FIPS certificate when the SP 800-131A transitions were enforced.
> number of non-FIPS approved algorithms/ services which are still
> implemented by the FIPS canister modules (e.g. RSA, DSA, DRDB, ECDSA etc).
>
> Just wondering why these algorithms are still implemented by FIPS Canister.
>
> The concern is, if these algorithms could still be used under FIPS mode,
> there is risk that the applications which use the FIPS canister modules may
> become non-FIPS compliant if these algorithms are used by mistake.
You are correct. It is possible for an application to use the OpenSSL FOM in a non-approved way by calling a non-approved service listed in Table 4c of the OpenSSL FOM Security Policy. I'm sure it was easier for the OpenSSL team to make documentation changes (rather than making coding changes and performing additional FIPS testing) to maintain the validity of the FIPS certificate when the SP 800-131A transitions were enforced.
A coding change to the FIPS canister would require review by the FIPS Laboratory. If any of the updates were found to be security relevant (from a FIPS perspective), then a FIPS revalidation effort involving additional testing would be required. As you know, there are many, many, many "Tested Configurations" (operating systems+hardware platforms) listed for the OpenSSL FOM certificates. A revalidation would result in a new OpenSSL FOM FIPS certificate and all of the previously tested configurations (that people care about) would need to be retested. Yikes.
Here is some background for those interested...
At the time of the original OpenSSL FOM validation, FIPS 140-2 allowed the use of an ANS X9.31 RNG. Digital signature functions could be performed using key sizes that provided an equivalent strength of 80 bits or greater. With the transition timelines documented in SP 800-131A, FIPS modules today must use only SP 800-90A DRBGs (for key generation) and >= 112 bits of equivalent strength for digital signature functions (although digital signature verification may be performed at previously allowed key sizes for legacy purposes). The services provided by the OpenSSL FOM that do not meet current SP 800-131A requirements are now listed as non-approved services in Table 4c of the OpenSSL FOM Security Policy.
Mark J. Minnoch
Co-Founder, CISSP, CISA
KeyPair Consulting
+1 (805) 550-3231 mobile
We expertly guide technology companies in achieving their FIPS 140 goals
New blog post: You Have Your FIPS Certificate. Now What?
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
