systemd-cryptsetup fails to unseal secret from TPM #30546
Labels
Comments
|
Not actionable. please provide debug logs of the cryptsetup part of the boot. |
poettering
added
the
ci-fails/needs-rework 🔥
bluca
added
needs-reporter-feedback ❓
|
I added Working example (systemd 254.6)Broken example (systemd 255.1) |
So it appears your PCR 11 and PCR 7 have changed and no matching signature for them are available. |
|
Are you implying that the problem is with my setup/config? Because I can reliably fix/reproduce the problem by changing just the systemd packages on my system ( PCR 7 is the same. And I use the same tooling ( Do you have any suggestions on how I might debug this further? |
bluca
removed
the
needs-reporter-feedback ❓
|
I bisected this problem to this commit. |
|
cc @ddstreet |
So, your PCR 11 is definitely different between the two logs; are you saying that you are separately enrolling for each setup, and only one fails to unlock your drive? Or are you saying that you enrolled using one setup, which correctly unlocks, but the other setup (with different PCR 11 value) fails to unlock the previously-enrolled drive? It would help if you provided the specific command(s) you used to enroll the TPM in your LUKS drive, as that's a very important part of this. |
|
PCR 11 is necessarily different, since there are different systemd binaries present in the initrd. So yes, I am regenerating the initrd, and creating different TPM2 PCR signature JSONs, and only one fails to unlock the drive. bisect.sh
My My For key enrollment I just used I hope this all the info you need :) |
|
Ah, ok, so yes that commit did alter the signing key public header which would then alter the key "name" (which is the hash of TPM header fields and RSA public key data) for the public key used for signature verification, which would change the session policy digest (since tpm_authorize uses the key name for the digest hash). The differences are that previously the @poettering so unfortunately it looks like my commit is causing a bit of a problem, due to above-described PEM->TPM2B_PUBLIC difference between We could add a fallback check when unsealing to try again with the previous PEM->TPM2B_PUBLIC method, which might be the best way to handle it. I'll work on a patch to add this, to see if it's possible without too much added complexity. |
|
@Faerbit since you already have the setup to rebuild and test this, can you do a quick check with this patch: |
|
@ddstreet I applied your patch on top of |
use this as well: |
|
Using the second patch as well seems to solve the problem! Do you still need logs, if so of what configuration? |
|
After reviewing the tpm2-tss marshal/unmarshal code, the first patch shouldn't be needed, because marshalling for a TPM2_ALG_NULL field elides the entire rest of the field, so when |
ddstreet
added a commit
to ddstreet/systemd
that referenced
this issue
Jan 16, 2024
…B_PUBLIC conversion The TPM specification defines a special case "default" exponent value, which can be indicated by an exponent value of 0 in the TPM2B_PUBLIC struct; however we have no need to special-case it in our conversion, and in fact doing so breaks backwards compatibility, since it changes the "name" of the TPM2B_PUBLIC key, which then changes the policy hash for any sealed data that used the policy Authorize. Fixes: systemd#30546
ddstreet
added a commit
to ddstreet/systemd
that referenced
this issue
Jan 16, 2024
…B_PUBLIC conversion The TPM specification defines a special case "default" exponent value, which can be indicated by an exponent value of 0 in the TPM2B_PUBLIC struct; however we have no need to special-case it in our conversion, and in fact doing so breaks backwards compatibility, since it changes the "name" of the TPM2B_PUBLIC key, which then changes the policy hash for any sealed data that used the policy Authorize. Fixes: systemd#30546
ddstreet
added a commit
to ddstreet/systemd
that referenced
this issue
Jan 16, 2024
…B_PUBLIC conversion The TPM specification defines a special case "default" exponent value, which can be indicated by an exponent value of 0 in the TPM2B_PUBLIC struct; however we have no need to special-case it in our conversion, and in fact doing so breaks backwards compatibility, since it changes the "name" of the TPM2B_PUBLIC key, which then changes the policy hash for any sealed data that used the policy Authorize. Fixes a bug introduced by commit e3acb4d. Fixes: systemd#30546
ddstreet
added a commit
to ddstreet/systemd
that referenced
this issue
Jan 16, 2024
…B_PUBLIC conversion The openssl default value for an RSA key exponent value is 0x10001, and the TPM specification defines a exponent value of 0 as representing this value. The systemd code that converted an RSA PEM public key to a TPM2B_PUBLIC object previously used the exponent value directly, but commit e3acb4d changed the conversion to use the special case exponent value of 0 for any RSA key with an exponent value of 0x10001. Because the entire TPM2B_PUBLIC object is used to calculate its "name", this difference in exponent value (0x10001 vs 0) introduced a change in the key "name". Since the Authorize policy uses the key "name" directly in its policy session hash value, this change resulted in new systemd code being unable to properly unseal any data (e.g. a LUKS volume) that was previously sealed. This reverts the code to no longer override an RSA exponent value of 0x10001 with the special case value of 0. Fixes a bug introduced by commit e3acb4d. Fixes: systemd#30546
ddstreet
added a commit
to ddstreet/systemd
that referenced
this issue
Jan 16, 2024
…ests Check the calculated TPM2B_PUBLIC key "name" to verify our PEM->TPM2B_PUBLIC function remains consistent with previous code. This is important as the TPM2B_PUBLIC "name" is used in the Authorize policy and so any change to a key "name" would break unsealing for previously-sealed objects (see bug systemd#30546).
ddstreet
added a commit
to ddstreet/systemd
that referenced
this issue
Jan 16, 2024
…ests Check the calculated TPM2B_PUBLIC key "name" to verify our PEM->TPM2B_PUBLIC function remains consistent with previous code. This is important as the TPM2B_PUBLIC "name" is used in the Authorize policy and so any change to a key "name" would break unsealing for previously-sealed objects (see bug systemd#30546).
ddstreet
added a commit
to ddstreet/systemd
that referenced
this issue
Jan 16, 2024
…ests Check the calculated TPM2B_PUBLIC key "name" to verify our PEM->TPM2B_PUBLIC function remains consistent with previous code. This is important as the TPM2B_PUBLIC "name" is used in the Authorize policy and so any change to a key "name" would break unsealing for previously-sealed objects (see bug systemd#30546). Note that the tpm2_tpm2b_public_from_openssl_pkey() function results in a TPM2B_PUBLIC with the same "name" as using the tpm2-tools program tpm2_loadexternal, at least as of tpm2-tools version 5.6.18, with the test keys from TEST(tpm2b_public_from_openssl_pkey) in src/test/test-tpm2.
LiveFreeAndRoam
pushed a commit
to LiveFreeAndRoam/systemd
that referenced
this issue
Jan 22, 2024
…B_PUBLIC conversion The openssl default value for an RSA key exponent value is 0x10001, and the TPM specification defines a exponent value of 0 as representing this value. The systemd code that converted an RSA PEM public key to a TPM2B_PUBLIC object previously used the exponent value directly, but commit e3acb4d changed the conversion to use the special case exponent value of 0 for any RSA key with an exponent value of 0x10001. Because the entire TPM2B_PUBLIC object is used to calculate its "name", this difference in exponent value (0x10001 vs 0) introduced a change in the key "name". Since the Authorize policy uses the key "name" directly in its policy session hash value, this change resulted in new systemd code being unable to properly unseal any data (e.g. a LUKS volume) that was previously sealed. This reverts the code to no longer override an RSA exponent value of 0x10001 with the special case value of 0. Fixes a bug introduced by commit e3acb4d. Fixes: systemd#30546
LiveFreeAndRoam
pushed a commit
to LiveFreeAndRoam/systemd
that referenced
this issue
Jan 22, 2024
…ests Check the calculated TPM2B_PUBLIC key "name" to verify our PEM->TPM2B_PUBLIC function remains consistent with previous code. This is important as the TPM2B_PUBLIC "name" is used in the Authorize policy and so any change to a key "name" would break unsealing for previously-sealed objects (see bug systemd#30546). Note that the tpm2_tpm2b_public_from_openssl_pkey() function results in a TPM2B_PUBLIC with the same "name" as using the tpm2-tools program tpm2_loadexternal, at least as of tpm2-tools version 5.6.18, with the test keys from TEST(tpm2b_public_from_openssl_pkey) in src/test/test-tpm2.
intelfx
pushed a commit
to intelfx/systemd
that referenced
this issue
Feb 2, 2024
…B_PUBLIC conversion The openssl default value for an RSA key exponent value is 0x10001, and the TPM specification defines a exponent value of 0 as representing this value. The systemd code that converted an RSA PEM public key to a TPM2B_PUBLIC object previously used the exponent value directly, but commit e3acb4d changed the conversion to use the special case exponent value of 0 for any RSA key with an exponent value of 0x10001. Because the entire TPM2B_PUBLIC object is used to calculate its "name", this difference in exponent value (0x10001 vs 0) introduced a change in the key "name". Since the Authorize policy uses the key "name" directly in its policy session hash value, this change resulted in new systemd code being unable to properly unseal any data (e.g. a LUKS volume) that was previously sealed. This reverts the code to no longer override an RSA exponent value of 0x10001 with the special case value of 0. Fixes a bug introduced by commit e3acb4d. Fixes: systemd#30546 (cherry picked from commit 1242b9a)
intelfx
pushed a commit
to intelfx/systemd
that referenced
this issue
Feb 2, 2024
…ests Check the calculated TPM2B_PUBLIC key "name" to verify our PEM->TPM2B_PUBLIC function remains consistent with previous code. This is important as the TPM2B_PUBLIC "name" is used in the Authorize policy and so any change to a key "name" would break unsealing for previously-sealed objects (see bug systemd#30546). Note that the tpm2_tpm2b_public_from_openssl_pkey() function results in a TPM2B_PUBLIC with the same "name" as using the tpm2-tools program tpm2_loadexternal, at least as of tpm2-tools version 5.6.18, with the test keys from TEST(tpm2b_public_from_openssl_pkey) in src/test/test-tpm2. (cherry picked from commit e2e8d8f)
|
this is the only google result if you search for "Failed to unseal secret using TPM2: Operation not permitted", so someone please help me, my partition won't decrypt automatically
journalctl -b | grep systemd |
journalctl -b | grep systemd-crypt (after enabling debug logs)P.S.:
apparently that's too much. i just tried with
and it decrypted successfuly. (btw are commas vs pluses significant?) P.P.S: apparently it stops working when i enable either 11 or 15 (even though they don't change) this works
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
systemd version the issue has been seen with
255.1-1-arch
Used distribution
Arch Linux
Linux kernel version used
6.6.7-arch1-1
CPU architectures issue was seen on
x86_64
Component
systemd-cryptsetup
Expected behaviour you didn't see
systemd-cryptsetup unseals secret from TPM to use with systemd-cryptenroll TPM2 signed PCR to unlock my rootfs.
(I'm unsure what additional details might be relevant, so please just ask for them)
Unexpected behaviour you saw
from journald
(again if additional log entries are relevant, please ask)
Steps to reproduce the problem
man systemd-measureDowngrade to systemd 254.6-2-arch fixes my setup, so this seems to be a regression.
Note to self: Use
journalctl -b 7a36c04369b14c7f8fa959fb2bdc4c3cfor additional details if necessaryAdditional program output to the terminal or log subsystem illustrating the issue
No response
The text was updated successfully, but these errors were encountered: