ciphers/signatures: Reject update if module isn't operational

[neverpanic]

When a FIPS self-test such as for example a pair-wise consistency test fails, the module should go into an error state and refuse any further cryptographic operations.

This is not the case for the RSA or ECDSA pair-wise consistency test, after which EVP_DigestUpdate() and EVP_EncryptUpdate() can still be called.

Add invocations of ossl_prov_is_running() to provider functions called by EVP_DigestUpdate() and EVP_EncryptUpdate() to fix this.

I am aware that new contexts cannot be created, and existing contexts cannot be finalized because the init and final variants of those APIs have the ossl_is_prov_running() call, but our lab claims that is not sufficient, and the update API must also not work on PCT failure.

We added an abort() downstream for these cases, since it's really a corner case that essentially never happens outside of bit-flips, but that's clearly not appropriate upstream, and neither is it a clean solution. In order to reduce our downstream patches, I'm proposing this instead.

[t8m]

For DigestUpdate there is no consequence of this check missing as there is no output generated until DigestFinal() is called. So it is doubtful whether this is really mandated by the FIPS 140 standard. On the other hand CipherUpdate produces an output so this seems like a bug to me.

[neverpanic]

For DigestUpdate there is no consequence of this check missing as there is no output generated until DigestFinal() is called. So it is doubtful whether this is really mandated by the FIPS 140 standard.

That was also what we argued, but considering that a hashing operation may be triggered in DigestUpdate(), our lab did not accept this explanation.

[paulidale]

Your lab is mistaken. Push back harder. Laugh at them if need be. If they are not willing to be reasonable, request a formal CMVP ruling about this and present your argument there. Be warned that such rulings can result in detrimental outcomes so you need to be prepared and very persistent.

Our 140-2 validation passed with things are they are. We've heard of no issues with this in KeyPair's 140-3 validation (upon which ours is based). It's simply not required. What's currently there meets the letter and intent of the requirement.

I strongly oppose this change, it introduces what could potentially be a performance regression. The update functions were deliberately excluded from the running checks because of this concern. I.e. the current behaviour is intentional and will not be changed.

[neverpanic]

Thanks for the review, I'll go back to them and see what we can do.

[mattcaswell]

Closing since this is marked as resolved.

[neverpanic]

We actually haven't heard back from NIST on this. I'll make sure to ask for a status update in our next meeting with our lab.

They wouldn't let us submit without a change to address this concern, so we're still very much interested in a resolution where we don't have to carry downstream patches.

I'll come back with more info when I have it.