2

I'm wondering how C_DecryptFinal & C_Decrypt are supposed to deal with padding errors.

According to pkcs11 2.20, C_DecryptFinal can return CKR_ENCRYPTED_DATA_INVALID or CKR_ENCRYPTED_DATA_LEN_RANGE, so I suppose that if padding is invalid, C_DecryptFinal/C_Decrypt return CKR_ENCRYPTED_DATA_INVALID.

Is it correct?

If so, is C_DecryptFinal/C_Decrypt vulnerable to padding-oracle attacks?

vlp
  • 7,811
  • 2
  • 23
  • 51
klook
  • 41
  • 2
  • I remember something vaguely about pading-oracle attacks on some particular hardware devices (or maybe their PKCS11 drivers). You need to ask google about this, but I am sure that you *will* find something related to your question. – Eugene Mayevski 'Callback Nov 04 '15 at 18:30

1 Answers1

2

Citing the standard (section 11.1.6):

  • CKR_ENCRYPTED_DATA_LEN_RANGE: The ciphertext input to a decryption operation has been determined to be invalid ciphertext solely on the basis of its length. Depending on the operation’s mechanism, this could mean that the ciphertext is too short, too long, or is not a multiple of some particular blocksize. This return value has higher priority than CKR_ENCRYPTED_DATA_INVALID.

  • CKR_ENCRYPTED_DATA_INVALID: The encrypted input to a decryption operation has been determined to be invalid ciphertext. This return value has lower priority than CKR_ENCRYPTED_DATA_LEN_RANGE.

So for block ciphers the CKR_ENCRYPTED_DATA_LEN_RANGE should be returned when the input is not block-aligned.

If the input is block-aligned, the CKR_ENCRYPTED_DATA_INVALID is probably returned in case of wrong padding for the CKM_*_PAD mechanisms.

Thus the padding oracle attack is probably possible.

As the PKCS#7 padding is the only defined padding scheme for block ciphers, it is quite often the responsibility of the application to handle the padding, which leads to what I think should be the answer to your question:

  • It is up to the application (i.e. "the cryptoki client") not to provide an external attacker (i.e. the "the application client") with any oracle to determine the padding was wrong, regardless of the source of this information (i.e. the cryptoki or the application itself).

  • It is probably meaningless to protect against the padding oracle attack on the cryptoki interface level (i.e. an attacker inside the application), as such an attacker can decrypt anything at will directly using the appropriate functions.

(Of course it is better to use some form of authenticated encryption and do not need to worry about the padding oracle attack at all)

Desclaimer: I am no crypto expert, so please do validate my thoughts.

vlp
  • 7,811
  • 2
  • 23
  • 51
  • Thx for your answer, indeed CKR_DATA_INVALID seems to be to most appropriate error to return when an invalid padding is detected. – klook Nov 05 '15 at 09:45
  • @klook It might be interesting to write a POC code to perform the padding oracle attack against some pkcs11 implementation (or adopt an existing one to pkcs11), but as I tried to express in the answer -- this padding oracle should be available only to the application (i.e. the "cryptoki client", who is already authorized to decrypt directly) so there is nothing to gain by using this type of attack (by the application). And it is the application responsibility not to allow an external attacker (i.e. the "application client") to gain access to the padding oracle. Does this answer your question? – vlp Nov 05 '15 at 10:11
  • According to https://eprint.iacr.org/2012/417.pdf the best solution to avoid padding oracle issues is to use an authenticated cipher-mode such as GCM so i think CKR_DATA_INVALID can be used without second thought. – klook Nov 05 '15 at 10:26
  • @klook edited the answer in line with the previous comment. – vlp Nov 05 '15 at 10:26
  • @klook That is correct and is mentioned in the answer. What do you mean by the CKR_DATA_INVALID can be used without second thought? That you can provide the application client with this error code if authenticated encryption is used? – vlp Nov 05 '15 at 10:32
  • @klook The paper mentioned is about using the padding oracle attack to extract a value of a wrapped key and is about `C_UnwrapKey` function and not `C_DecryptFinal`/`C_Decrypt`. If an attacker had access to `C_Decrypt` for a key used to wrap any other key it is trivial to get the wrapped key value. – vlp Nov 05 '15 at 10:48
  • Regarding the attacks described in the paper, there are vendor specific solutions, e.g. SafeNet's `CKA_IMPORT` which can be used to force `CKM_WRAPKEY_[DES3/AES]_CBC` mechanism (which uses authentication) for `C_Unwrap`. – vlp Nov 05 '15 at 11:03
  • what i meant is that as long as you use an authenticated mode, returning CKR_DATA_INVALID is not an issue because an attacker won't be able to mount a chosen-cipher attack. – klook Nov 05 '15 at 11:18
  • Given that pkcs11 does not define any combined authenticated mode right now(AFAIK): An attempt with modified ciphertext would fail during the signature verification phase with a different error code (probably a `CKR_SIGNATURE_INVALID`) – vlp Nov 05 '15 at 11:24
  • @klook ...we are slowly getting out of scope of the question (and maybe out of scope of this site as well) :) – vlp Nov 05 '15 at 11:26