Re: Using different cipher suites in a BCFIPS JDK, triggers RSA key-reuse

Hi Erik,
Your diagnosis is basically correct, TLS_RSA_* cipher suites (RSA key
exchange) have the server decrypting using an RSA key. TLS_*_RSA_*
cipher suites have the server signing with an RSA key.

Since you are using BCFIPS without BCJSSE, I think the only option is to
restrict the cipher suites enabled on the server (presumably disabling
all TLS_RSA_* ones). I gather you are hoping for a global disable, but I
don't know of any in SunJSSE.

If using BCJSSE in FIPS mode, there is a boolean system property to
enable/disable RSA key exchange (defaults to allowed at the moment):
    "org.bouncycastle.jsse.fips.allowRSAKeyExchange"

In principle, the KeyUsage extension for an RSA certificate could be
used to restrict it to either digitalSignature or keyEncipherment.
However, at least up until JDK8, the default KeyManagerFactory
("SunX509") doesn't make that distinction (actually can't, since it only
understands a request for an "RSA" certificate, without qualification).

In the BCJSSE provider, our "PKIX" KeyManagerFactory will respect a
KeyUsage extension if present, but that can only work with our own SSL
implementation since it requires the SSL server to ask for e.g.
"ECDHE_RSA" to get a signing cert. This allows to have separate RSA
credentials for the decryption/signing cases in the same key store (with
distinct keys and KeyUsage values).

Regards,
Pete Dettman


On 21/6/18 4:10 pm, Erik Bergfur wrote:
> We are using BCFIPS as the com.sun.net.ssl.internal.ssl.Provider
> 
> During SSL client / server handshake, our internal components choose
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as cipher suite when talking to our
> HTTP-server.
> 
> An AWS ELB then comes along and selects TLS_RSA_WITH_AES_256_CBC_SHA as
> cipher suite. This results in the server failing during handshake with
> the following message:
> 
>  
> 
> org.bouncycastle.crypto.IllegalKeyException: Attempt to encrypt/decrypt
> with RSA modulus already used for sign/verify
> 
>  
> 
> If the healthcheck calls on our HTTP-server before our internal
> components, then it’s the internal components that trigger a key reuse
> error on the server.
> 
>  
> 
> I have identified which cipher suites are incompatible with trial and
> error but really don’t understand what is causing the issue, other than
> assuming that some cipher suites use the RSA key for encrypt / decrypt,
> while others are using it for signing / verifying.
> 
> Our way forward will be to restrict cipher suite uses in the server with
> all SSL handshakes we perform. I would love to set this restriction on
> JDK level though, to make sure that no new code “poisons†the JVM with
> the wrong cipher suite.
> 
> Does anyone else have any insights in this problem? Can this be locked
> down on JDK level (i.e. java.security / some kind of JSSE provider)?
> 
> Thanks
> 
>   Erik
> 
>  
>