Page MenuHome GnuPG

Implement service indicators
Open, HighPublic

Description

The FIPS 140-3 requires service indicators. There are couple of notes from previous email discussion to keep them in one place:

The last paragraph of ISO 19790:2012 section 7.2.4.2 states:

All services shall [02.24] provide an indicator when the service utilises an approved cryptographic algorithm, security function or process in an approved manner and those services

or processes specified in 7.4.3

This means our libraries need to grow an API or provide some additional information via contexts or similar in order for an application to be able to query this indicator. This can't be just a Security Policy description because ISO 24759:2017 section 6.2.4.2 states:

TE02.24.02: The tester shall execute all services and verify that the indicator provides an unambiguous indication of whether the service utilizes an approved cryptographic algorithm,

security function or process in an approved manner or not.

The indicator can't be just a marker over an algorithm either, because it needs to show different values based on whether the algorithm parameters cause the algorithm to run in approved or non-approved mode (ie keys outside of valid range for RSA means RSA is being used in non-approved mode ...)

More comments from Simo:

[...] in short we have two ways to go about it:

  1. provide a context to every "service" we provide (services can be as simple as "AES encrypt operation" or as complicated as "apply GPG signature to a document") and then make an API available to consult this context and find if all algorithms used to implement the service were FIPS approved. This includes also that key sizes or other parameters are within FIPS allowed parameters. So for example a service that provides RSA encryption, should return an indicator of "approved" if key sizes are > 2048 bit, and "not approved" if key sizes are <2048.

This would require huge changes in libgcrypt so it is probably not a way to go.

  1. Provide an "implicit" indicator. An implicit indicator can be the return code of a function. In this case a successful outcome would require that only approved FIPS algorithms can be used to implement the service. IE any non approved algorithm or key size (or other parameter) would have to be blocked when the library is operating in FIPS mode.

As far as I understand this here, this quite much what is done in libgcrypt now. But it might need to review the algorithms and key sizes to make sure the rules are enforced everywhere.

Event Timeline

werner triaged this task as High priority.Jun 28 2021, 1:27 PM
werner added subscribers: werner, gniibe.

Just FYI, NSS offers following API:

/* FIPS indicator functions. Some operations are physically allowed, but
 * are against the NSS FIPS security policy. This is because sometimes NSS
 * functions are used in non-security contexts. You can call these functions
 * to determine if you are operating inside or outside the the current vendor's
 * FIPS Security Policy for NSS. NOTE: if the current version of NSS is not
 * actually FIPS certified, then these functions will always return PR_FALSE */

/* This function tells if if the last single shot operation on the slot
 * was inside or outside the FIPS security policy */
PRBool PK11_SlotGetLastFIPSStatus(PK11SlotInfo *slot);
/* This tells you if the current operation is within the FIPS security policy. If
 * you have called finalize on the context, it tells you if the last operation
 * was within the FIPS security policy */
PRBool PK11_ContextGetFIPSStatus(PK11Context *context);
/* This tells you if the requested object was created in accordance to the
 * NSS FIPS security policy. */
PRBool PK11_ObjectGetFIPSStatus(PK11ObjectType objType, void *objSpec);

I went through the OpenSSL drafts. The module boundary in OpenSSL will be separate fips.so object and only non-deprecated functions of OpenSSL 3.0 will be FIPS compliant. There is a global state, that will allow only approved algorithms and modes and there will be API to query the FIPS mode status using OSSL_PARAM_get* functions, but we still have some unknowns so I hope we will know more on the next meeting.