The newest version the dev-libs/libtpms discloses the following problem: Note: The TPM 2 implementation returns 2048 bit keys with ~1984 bit strength due to a bug in the TPM 2 key creation algo that cannot easily be fixed. The bug is in RsaAjustPrimeCandidate, which is called before the prime number check. It'll be be fixed in 0.8.0 (not released yet), but upgrading won't be sufficient. The only way to fix it is to unseal all data, delete the old TPM state file, generate a new one, then reseal the data.
Thank you for the report! In, the PR, don't we need 0.8.0 to fix the vulnerability (https://github.com/stefanberger/libtpms/commit/c1f7bf55099fcd427715aa65e130475c6e836a6b)? Looks like there might be other things fixed that might be security-relevant too: Fix output buffer parameter and size for RSA decryption that could cause stack corruption under certain circumstances Fixes to symmetric decryption related to input size check, defer padding to the user [EVP_CIPHER_CTX_set_padding(ctx, 0)] and to always use a temporary malloc'ed buffer for decryption
Upstream released 0.8.0 a few hours ago. I'm preparing an ebuild for it. Upgrading is necessary but not sufficient though. Any "seeds" generated prior to 0.8.0 will continue to use the flawed algorithm until changed, either through TPM commands or a new state file is created. Either way, any material sealed under the old seeds will be permanently inaccessible after that.
(In reply to Salah Coronya from comment #2) > Upstream released 0.8.0 a few hours ago. I'm preparing an ebuild for it. > Upgrading is necessary but not sufficient though. Any "seeds" generated > prior to 0.8.0 will continue to use the flawed algorithm until changed, > either through TPM commands or a new state file is created. Either way, any > material sealed under the old seeds will be permanently inaccessible after > that. I'm not at all familiar with this technology, is it at all possible to mitigate the issue on older seeds (maybe by using new seeds, somehow?)? Would it be possible to provide a short mitigation path via elog or similar (or link to somewhere that tells how to do it)?
There no really good generic way to migrate. Anyone using RSA keys and the virtual TPM 2 functionality (via swtpm) would need to decrypt (or have backups) of affected data, generate new seeds (most likely by deleting the state file and recreating it, then reeecrypt. There are TPM 2 commands to change the seeds, and the very least the Owner one would need to be changed vith a tpm2_clear - which has other side effects like clearing the NVRAM. The other seeds are more complicated). I think the best that can be done is to inform the user (via elog?) that versions of libtpms before 0.8.0 generate weaker than expected TPM 2.0 RSA keys due to a flawed key creation algorithm. Because fixing this would render existing sealed data inaccessible, to use the corrected algorithm, the old TPM state file must be deleted and a new TPM state file created for that. Any data still sealed to the virtual TPM will be rendered permanently inaccessible after that.
> I think the best that can be done is to inform the user (via elog?) that > versions of libtpms before 0.8.0 generate weaker than expected TPM 2.0 RSA > keys due to a flawed key creation algorithm. Because fixing this would > render existing sealed data inaccessible, to use the corrected algorithm, > the old TPM state file must be deleted and a new TPM state file created for > that. Any data still sealed to the virtual TPM will be rendered permanently > inaccessible after that. Yes, a short elog message explaining the incompatibility and a link to the bug would be great.
Upstream has released 0.8.2: CryptSym: fix AES output IV A CVE has been filed for this bugfix. Unfortunately multi-step encrypted data won't decrypt anymore but are now compatible with other TPM 2 devices.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ac52bd092b79ddbbaa2be30822d27dc4eb563f0c commit ac52bd092b79ddbbaa2be30822d27dc4eb563f0c Author: Salah Coronya <salah.coronya@gmail.com> AuthorDate: 2021-02-27 02:36:28 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2021-03-06 15:12:52 +0000 dev-libs/libtpms: Bump to 0.8.2 Bug: https://bugs.gentoo.org/772410 Package-Manager: Portage-3.0.13, Repoman-3.0.2 Signed-off-by: Salah Coronya <salah.coronya@gmail.com> Signed-off-by: Joonas Niilola <juippis@gentoo.org> dev-libs/libtpms/Manifest | 1 + .../files/libtpms-0.8.0-Remove-WError.patch | 13 ++++++ dev-libs/libtpms/libtpms-0.8.2.ebuild | 48 ++++++++++++++++++++++ 3 files changed, 62 insertions(+)
Please cleanup. Given the incompatibility it should be fine to wait just a bit.
Hello Salah, (In reply to Salah Coronya from comment #6) > A CVE has been filed for this bugfix. Unfortunately multi-step encrypted > data won't decrypt anymore but are now compatible with other TPM 2 devices. Was the CVE assigned for this issue? If not, I can go ahead and request a new one if you wish.
Its CVE-2021-3446
(In reply to Salah Coronya from comment #10) > Its CVE-2021-3446 Actually, I meant a new CVE for the original issue reported with this bug (RSA keys weaker than expected). That is different from CVE-2021-3446, isn't it? Specifically, it looks like the issue discussed here was fixed in libtpms v0.8.0 (April 2020): https://github.com/stefanberger/libtpms/commit/625171be0c8225824740b5d0fb7e8562f6a1c6a8 https://github.com/stefanberger/libtpms/commit/c1f7bf55099fcd427715aa65e130475c6e836a6b While CVE-2021-3446 was fixed recently in v0.8.2 (March 2021): https://github.com/stefanberger/libtpms/commit/32c159ab53db703749a8f90430cdc7b20b00975e I'm wondering if we should get a CVE for the "weak RSA key" issue, even though it doesn't seem feasible to backport the fix to older versions (0.7.x).
Yeah, different issue. The RSA problem is described here: https://github.com/stefanberger/libtpms/issues/183 . Upstream never requested a CVE for this issue. If you feel one is needed, go ahead.
Ah, I see this has been cleaned up. All done, thanks!
