SSH RSA 1024 keys are allowed for usage when FIPS 140-3 enabled

[JohnEnzinas]

We may have found an inconsistency in BCFIPS 2.1.0 when running in approved-only mode.

Expected:

• 1024-bit RSA keys should be rejected in approved-only/FIPS mode.

Observed:

• A 1024-bit RSA key is correctly rejected in a signing/authentication flow with:
  FipsUnapprovedOperationError: Attempt to use RSA key with non-approved size: 1024: RSA
• But a 1024-bit RSA key appears to be accepted in a signature verification / SSH public key authentication flow, with no error thrown.

The verification path reaches:

org.bouncycastle.crypto.fips.FipsRSA$SignatureOperatorFactory.createVerifier
org.bouncycastle.jcajce.provider.ProvRSA$AdaptiveSignatureOperatorFactory.createVerifier
org.bouncycastle.jcajce.provider.BaseSignature.initVerify
java.security.Signature.initVerify

For comparison, the failing signing path reaches:

org.bouncycastle.crypto.fips.FipsRSA$SignatureOperatorFactory.createSigner
org.bouncycastle.jcajce.provider.ProvRSA$AdaptiveSignatureOperatorFactory.createSigner
org.bouncycastle.jcajce.provider.BaseSignature.initSign
java.security.Signature.initSign

We suspect there may be a gap in how RSA key size is enforced for createVerifier(...) versus createSigner(...) in approved-only mode.

[xnox]

• But a 1024-bit RSA key appears to be accepted in a signature verification / SSH public key authentication flow, with no error thrown.

As is allowed, and documented in the security policy for the RSA Key Verification service; the key verification is available for the strengths "80, 112, 128, 152 bits".

Note - every module is free to implement things as they wish; and depending on when things are submitted different rules apply. Thus there is no consistency across modules (some modules choose to block less than 2k RSA keys for all operations; or chose not to implement RSA at all), thus one has to consult the security policy for each specific service as different rules can apply between key generation; key verification; signature creation; signature verification and so on - even for the same algorithm.

If you want to block RSA keys lower than 2k for verification; you can use java.security settings (existing ones, and the improved ones coming in next quarterly java update).

ps. I am an independent community user of bc-java; i am not affiliated with bc-java project.

[JohnEnzinas]

So that make sense but it looks like it's in conflict with the Approved Algorithms table that says you can't use anything less than a 2048 RSA key for signature generation and verification. Am I missing something?

[xnox]

So that make sense but it looks like it's in conflict with the Approved Algorithms table that says you can't use anything less than a 2048 RSA key for signature generation and verification. Am I missing something?

Approved Algorithms table shows the sizes that are tested. Note that RSA algorithm also appears in the non-approved algorithms table. Also annoyingly there is requirement to document tested and internal algorithms; but they do not need to be exposed as services. For example for a long time there was no testing for SHA3 in higher algorithms - yet these were approved or allowed or non-approved depending on the module.

Specifically for RSA, one can use higher / intermediate / lower values of moduli, than the ones tested. Usually security policy state a paragraph if this is the case - that whilst specific moduli were tested that other sizes are supported too. Possibly this security policy lacks such an RSA standard paragraph based on the FIPS 140-3 IG guidance.

It would be interesting to see if you can enable non-approved indicator logging and check if any non-approved messages pop up.

Also would be interesting to see if the 8192 keys work. As that would be an indication that module supports arbitrary sizes; including those not tested with ACVP.

In general, do not rely on any module implementation to tell you if what you are doing is approved are not.

As in general, a lot of these algorithms and services are specific to particular types of application. For example only certain RSA padding modes are approved when doing only TLS. The module cannot know if it is being used as part of the TLS protocol or not. Thus padding modes are available in "approved only" when they should not be used in a general case. Ditto, some AES modes are only for in-transit and some are for storage applications only; and so on.