stefanberger / libtpms / 1729

77%

master: 77%

push

travis-ci-com

tpm2: Always return a value after pkcs1-padded RSA decryption

PKCS v1.5 padding is susceptible to Bleichenbacher attacks. The
TPM 2 supports this type of padding (and also raw decryption).
This patch tries to find an experimental work-around to the Bleichen-
bacher type of attacks, but the argument is that TPM 2 implements
low-level crypto primitives that higher layer software and devlopers
need to choose whether to use. To fool the attacker this patch now
returns messages even if the decryption failed.

We will not merge this because:
- The TCG TPM 2 code, which is equivalent of the spec of the TPM 2,
  does not do this and therefore higher layers don't expect decrpytion
  failures to return a message and a success status code.
- It is not clear how applications would react to decryption failures not
  returning a failure status code but a message instead. Decryption
  failures typically propagate through higer layers, such as TSS stacks,
  TPM 2 PKCS 11 modules, or TPM 2 OpenSSL engines, into appications.

My guidance would be:
Do not use pkcs1 padding for anything that offers some sort of
decryption service, such as a TPM 2 PKCS 11 module (if it offers this
type of padding at all) or a web server accessing the TPM 2 keys via
OpenSSL engine (if it offers this type of padding at all) or so.
You can use it for private encryption where you alone are using the
key. Better use OAEP padding.

With this patch we are returning a deterministic random message of
deterministic random length (less or equal to the max. message size)
when pkcs1 padding is being used for RSA encryption. The goal is to
avoid Bleichenbacher type of attacks that attempt to reconstruct an
RSA private key by sending thousands of probes for decryption and
checking which probe returns a message and therefore deducing that
the decryption lead to a correctly-looking padding, from which it
can deduce the private RSA key. We are basically drowning out these
random successes among the thousa... (continued)

31 of 31 new or added lines in 1 file covered. (100.0%)

28933 of 37380 relevant lines covered (77.4%)

88603.42 hits per line