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 184.108.40.206 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 220.127.116.11 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:
- 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.
- 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.