Do we know if users are depending on 1024-bit certs anywhere? Would be a shame to drop them just because our TPM 2.0 devices don't support that key size. I believe  bug 697671  noted a way to wrap keys, if we really want to support it.

It is of course nice to also test more reasonable key sizes.

+David for enterprise.

If I had to guess I'd say there are probably many sites that still use less-secure key sizes.  Maybe we could add an UMA histogram to quantify it, although that won't help for sites that have opted out.

Best bet IMO is to be as flexible as possible (and that includes prioritizing support for ECC client certs).  Not all IT environments will be optimized around Chrome OS' preferences.

Sorry, late arrival. Can someone please provide the tldr? What keys do the new TPMs support and what's the delta with the older TPMs?

In our key-generation API[1], we claim support for all keys up to 20148

"Only non-extractable RSASSA-PKCS1-V1_5 keys with modulusLength up to 2048 can be generated. Each key can be used for signing data at most once."

Many vendors are using this and we will need a deprecation path if we will not be holding on that statement.


Some more context would be useful so I can add more color here.


[1] https://developer.chrome.com/extensions/enterprise_platformKeys

For TPM 2.0 we support 2048-bit RSA keys only

Iirc this is the check that limits the supported RSA keys to >= 2048 bits for TPM 2.0:
https://chromium.googlesource.com/chromiumos/platform2/+/master/chaps/tpm2_utility_impl.cc#420 (with kMinModulusSize defined as 256 bytes).

The same constant is also used in Bind/Unbind, though, to limit the max size of plaintext that can be encrypted with a tpm-bound key. If we want to lower the limit w/o affecting what 2048 bit keys can do, there we should just switch from using the global constant to the modulus size obtained from the public area of the specific key we use to bind/unbind.

I can draft a CL that makes bind/unbind use a specific key size and lowers kMinModulusSize to 1024 bits. In my understanding, that should be sufficient to address this, provided TPM supports 1024-bit keys (more below).
dkrahn@, do you remember anything about this limit, that says it plays yet another role somewhere, and the fix is more complex than I described?

Note: it is not guaranteed that a TPM 2.0 chip supports for RSA anything but 2048 bits. Per spec: "A TPM that supports RSA should support a public modulus size of at least 2,048 bits. Support for other key sizes is permitted."

In our case H1/Cr50 is always used in 2.0 cases. Based on what I see in the Cr50 source code, it supports 1024 and 2048. Will need to double-check in practice.

Is lowering the min allowed RSA key size to 1024 bits sufficient? 
If we need to support smaller that 1024 bits key sizes (or generic tpm 2.0 chips), the fix will need to additionally include falling back to software for tpm 2.0 for all unsupported sizes. So, smaller keys won't be tpm-bound. Here we have constants that define min and max key sizes that can be tpm-bound: https://chromium.googlesource.com/chromiumos/platform/chaps/+/master/session_impl.cc#1276
Will need to change those to be tpm chip specific values instead.

Submitted https://chromium-review.googlesource.com/c/577147 for review.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/0636f98673421e529aac3ca00057c46419955742

commit 0636f98673421e529aac3ca00057c46419955742
Author: Andrey Pronin <apronin@chromium.org>
Date: Wed Jul 26 23:46:51 2017

chaps: use tpm-specific key size ranges to allow 1024 keys on tpm2

Before the change, in tpm2 case, chaps refused to wrap RSA keys
less than 2048 bits in size at the tpm utility layer, even though
the upper layers expected the tpm to support it.
This change introduces requesting min and max supported RSA key
sizes from the tpm utility layer. The min supported size for tpm2
is set to 1024 bits.

BUG= chromium:726057 
BUG= chromium:697671 
TEST=0) Unit tests.
     1) Generate 1024-bit RSA keypair and certificate:
        openssl req -nodes -x509 -sha1 -newkey rsa:1024 -keyout /tmp/priv.key \
                    -out /tmp/cert.crt
        openssl pkcs12 -export -out /tmp/cert.pfx -inkey /tmp/priv.key \
                       -in /tmp/cert.crt
        openssl rsa -pubout -in /tmp/priv.key -out /tmp/pub.key
        openssl pkcs8 -inform pem -outform der -in /tmp/priv.key \
                      -out /tmp/priv.der -nocrypt
     2) Verify that the generated private key is successfully imported:
        p11_replay --import --path=/tmp/priv.der --type=privkey \
                   --id=aaaaaa
     3) Verify that the imported private key can be used for signing
        (emerge and deploy opensc for pkcs11-tool):
        echo "ABCDEF" > /tmp/1.txt
        pkcs11-tool --module=`ls /usr/lib**/libchaps.so` --slot=0 \
                    --id=aaaaaa --sign -i /tmp/1.txt -o /tmp/1.sig \
                    -m SHA1-RSA-PKCS
        openssl dgst -sha1 -verify /tmp/pub.key -signature /tmp/1.sig \
                     /tmp/1.txt
     5) Verify that the generated cert.pfx can be imported through
        Settings > Manage certificates > Import and Bind.

Change-Id: I2591af496b9cf777b8b6c5a26426316127f8288b
Reviewed-on: https://chromium-review.googlesource.com/577147
Commit-Ready: Andrey Pronin <apronin@chromium.org>
Tested-by: Andrey Pronin <apronin@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>

[modify] https://crrev.com/0636f98673421e529aac3ca00057c46419955742/chaps/tpm2_utility_impl.cc
[modify] https://crrev.com/0636f98673421e529aac3ca00057c46419955742/chaps/tpm_utility_impl.h
[modify] https://crrev.com/0636f98673421e529aac3ca00057c46419955742/chaps/tpm_utility.h
[modify] https://crrev.com/0636f98673421e529aac3ca00057c46419955742/chaps/session_test.cc
[modify] https://crrev.com/0636f98673421e529aac3ca00057c46419955742/chaps/session_impl.cc
[modify] https://crrev.com/0636f98673421e529aac3ca00057c46419955742/chaps/tpm_utility_mock.h
[modify] https://crrev.com/0636f98673421e529aac3ca00057c46419955742/chaps/tpm2_utility_impl.h