Giters

ThalesGroup / crypto11

Implement crypto.Signer and crypto.Decrypter for HSM-protected keys via PKCS#11

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Crypto11 fails to perform decrypt operation

vareddy-zz opened this issue · comments

commented

Hi,
I’m currently using crypto11 to perform TLS handshakes with an RSA2048 private key stored in a TPM (using TrouSerS). When I try to make a TLS connection, using the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite, crypto11 fails to perform decrypt and errors out at this location (SessionKeyLen > 0).
I tried other cipher suites and it succeeds with any that use RSA+ECDHE (e.g. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) as they don’t require the decrypt operation and only use the sign operation.
Is this a known limitation of crpyto11, or are we doing something wrong? The same private key and cipher suite combination works when using GoLang's internal stack (i.e.. without TPM / Crypto11).


Thanks!

Varun

commented

This is (currently) a limitation of crypto11. If the SessionKeyLen option is nonzero then it refuses to decrypt. It is documented but I appreciate that it's easy to miss if you are using it as a drop-in replacement for the native implementation.

The reason lies in the definition of the option:

    // SessionKeyLen is the length of the session key that is being
    // decrypted. If not zero, then a padding error during decryption will
    // cause a random plaintext of this length to be returned rather than
    // an error. These alternatives happen in constant time.

The reason for this behavior is Daniel Bleichenbacher's attack on the PKCS#1v1.5 padding scheme.

crypto11 could (hypothetically) replace error responses with random plaintexts, but it cannot guarantee the constant-time behavior - that is something that only the underlying PKCS#11 implementation can control.

Rather than violate the promise in the API definition, I chose to have the code fail instead. I appreciate that this is not convenient, but I think it is the safer option.

If it's a major problem then I think we could have a runtime option which accept nonzero SessionKeyLen values and set random plaintext without the promise of constant-time behavior. It would be off by default and accompanied by a warning about the security risks of enabling it.

However, my recommendation is that you avoid ciphersuites that depend on PKCS#1v1.5 decryption, if that is possible.

References:

commented

Hi @nfewx,
Thanks a lot for the detailed explanation. The course of action you suggested looks good to me. I will close this issue.
Thanks!
Varun