Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LUKS header is not verified directly when a TPM Disk Unlock Key setuped/verified on default boot and fails unsealing #1092

Closed
tlaurion opened this issue Jan 19, 2022 · 1 comment · Fixed by #1625

Comments

@tlaurion
Copy link
Collaborator

@MrChromebox @kylerankin: what @Tonux599 proposed has a workflow is about having LUKS headers being verified prior of booting an OS from a LUKS container that may have been tampered with and different then measured, as reported by @rustybird on #1089 OP for possible LUKS2 existing vulns and future ones:

But attacks against LUKS may involve the crafting of an unusual header (CVE-2021-4122, QSB-019), and a hypothetical future attack of this type might not change the luksDump output at all.

#1090 (closed) #1091(merged) just replaces luksDump as requested in OP. But would not inform of what failed in measurements leading to a failed unsealing of TPM disk unlock key.

It would just refuse to unseal TPM LUKS sealed disk unlock key. Without telling why.

While not having LUKS disk unlock sealed file released by TPM leaves the user blunt about anything having happened on the LUKS container at all for the moment, other then #1091.

Originally posted by @tlaurion in #1089 (comment)

@tlaurion tlaurion changed the title LUKS header is only verified when setting a LUKS disk unlock key LUKS header is only verified when a TPM disk encryption key is setuped/verified on default boot Jan 19, 2022
@tlaurion
Copy link
Collaborator Author

tlaurion commented Jan 21, 2022

@root-hardenedvault changed the behavior of TPM sealed Disk Unlock Key from luksDump to luksBackupHeader under #1091, which whole binary headers are now hashed. That hash is then measured and sealed/unsealed as part of the TPM released disk unlock key when a default boot is configured to release such key from TPM NVRAM space when the the firmware measurements, loaded kernel modules, user config files (including public key injected in rom) are still consistent and while Heads haven't landed in recovery shell, which scrambles the PCR measurements.

Under #1093, he adds an additioanl verification when TPM Disk Unlock key passphrase is not able to release the Disk Unlock Key since measurements are incoherent. Since PCR 6 is now measuring the actual configured disks luksBackupHeaders, when the passphrase is unable to unlock TPM NVRAM region, an additional check is made to verify luksHeaderBackup hashes saved under /boot against to the one generated on the fly. If those are the same, a message is given to the user saying so.

This informs the user if the LUKS headers changed against detached signed /boot/kexec* files, every time TPM Disk Unlock Key passphrase is unable to release TPM Disk Unlock Key if the LUKS Headers did not change.

tlaurion added a commit to tlaurion/heads that referenced this issue May 3, 2022
…aling of TPM Disk Unlock Key.

Fixes linuxboot#1092.
Supersedes linuxboot#1093
- Cherry-picks ed1c23a (credit to @hardened-vault) thank you!)
- Addresses and correct self-review under linuxboot#1093 (@hardened-vault: you don't answer often here!)
  - kexec-unseal-key: Warn a user who attempts to default boot while his Disk Unlock Key passphrase fails to unseal because LUKS headers changed.
    (linuxboot#1093 (comment))
  - kexec-seal-key: Identical as in ed1c23a
  - kexec-add-key: Tell the user that the Headers did not change when changing TPM released Disk Unlock Key
    (Through changing default boot at Options->Boot Options -> Show OS boot options: select a new boot option
    and set a Disk Unlock Key in TPM, accept to modify disk and sign /boot options)
    - Here, we cancel the diff output shown on screen linuxboot#1093 (comment)
    - And we change the warning given to the user to past tense "Headers of LUKS containers to be unlocked via TPM Disk Unlock Key passphrase did not change."
tlaurion added a commit to tlaurion/heads that referenced this issue Mar 26, 2024
…sk Unlock Key.

Fixes linuxboot#1092.
Supersedes linuxboot#1093

- Cherry-picks ed1c23a (credit to @hardened-vault) thank you!)
- Addresses and correct self-review under linuxboot#1093 (@hardened-vault: you don't answer often here!)
  - kexec-unseal-key: Warn a user who attempts to default boot while his Disk Unlock Key passphrase fails to unseal because LUKS headers changed.
    (linuxboot#1093 (comment))
  - kexec-seal-key: Identical as in ed1c23a
  - kexec-add-key: Tell the user that the Headers did not change when changing TPM released Disk Unlock Key
    (Through changing default boot at Options->Boot Options -> Show OS boot options: select a new boot option
    and set a Disk Unlock Key in TPM, accept to modify disk and sign /boot options)
    - Here, we cancel the diff output shown on screen linuxboot#1093 (comment)
    - And we change the warning given to the user to past tense "Headers of LUKS containers to be unlocked via TPM Disk Unlock Key passphrase did not change."

Signed-off-by: Thierry Laurion <[email protected]>
tlaurion added a commit to tlaurion/heads that referenced this issue Apr 2, 2024
…sk Unlock Key.

Fixes linuxboot#1092.
Supersedes linuxboot#1093

- Cherry-picks ed1c23a (credit to @hardened-vault) thank you!)
- Addresses and correct self-review under linuxboot#1093 (@hardened-vault: you don't answer often here!)
  - kexec-unseal-key: Warn a user who attempts to default boot while his Disk Unlock Key passphrase fails to unseal because LUKS headers changed.
    (linuxboot#1093 (comment))
  - kexec-seal-key: Identical as in ed1c23a
  - kexec-add-key: Tell the user that the Headers did not change when changing TPM released Disk Unlock Key
    (Through changing default boot at Options->Boot Options -> Show OS boot options: select a new boot option
    and set a Disk Unlock Key in TPM, accept to modify disk and sign /boot options)
    - Here, we cancel the diff output shown on screen linuxboot#1093 (comment)
    - And we change the warning given to the user to past tense "Headers of LUKS containers to be unlocked via TPM Disk Unlock Key passphrase did not change."

Signed-off-by: Thierry Laurion <[email protected]>
@tlaurion tlaurion changed the title LUKS header is only verified when a TPM disk encryption key is setuped/verified on default boot LUKS header is not verified directly when a TPM Disk Unlock Key setuped/verified on default boot and fails unsealing Apr 2, 2024
tlaurion added a commit to tlaurion/heads that referenced this issue Apr 11, 2024
…sk Unlock Key.

Fixes linuxboot#1092.
Supersedes linuxboot#1093

- Cherry-picks ed1c23a (credit to @hardened-vault) thank you!)
- Addresses and correct self-review under linuxboot#1093 (@hardened-vault: you don't answer often here!)
  - kexec-unseal-key: Warn a user who attempts to default boot while his Disk Unlock Key passphrase fails to unseal because LUKS headers changed.
    (linuxboot#1093 (comment))
  - kexec-seal-key: Identical as in ed1c23a
  - kexec-add-key: Tell the user that the Headers did not change when changing TPM released Disk Unlock Key
    (Through changing default boot at Options->Boot Options -> Show OS boot options: select a new boot option
    and set a Disk Unlock Key in TPM, accept to modify disk and sign /boot options)
    - Here, we cancel the diff output shown on screen linuxboot#1093 (comment)
    - And we change the warning given to the user to past tense "Headers of LUKS containers to be unlocked via TPM Disk Unlock Key passphrase did not change."

Signed-off-by: Thierry Laurion <[email protected]>
tlaurion added a commit to tlaurion/heads that referenced this issue Apr 26, 2024
…sk Unlock Key.

Fixes linuxboot#1092.
Supersedes linuxboot#1093

- Cherry-picks ed1c23a (credit to @hardened-vault) thank you!)
- Addresses and correct self-review under linuxboot#1093 (@hardened-vault: you don't answer often here!)
  - kexec-unseal-key: Warn a user who attempts to default boot while his Disk Unlock Key passphrase fails to unseal because LUKS headers changed.
    (linuxboot#1093 (comment))
  - kexec-seal-key: Identical as in ed1c23a
  - kexec-add-key: Tell the user that the Headers did not change when changing TPM released Disk Unlock Key
    (Through changing default boot at Options->Boot Options -> Show OS boot options: select a new boot option
    and set a Disk Unlock Key in TPM, accept to modify disk and sign /boot options)
    - Here, we cancel the diff output shown on screen linuxboot#1093 (comment)
    - And we change the warning given to the user to past tense "Headers of LUKS containers to be unlocked via TPM Disk Unlock Key passphrase did not change."

Signed-off-by: Thierry Laurion <[email protected]>
tlaurion added a commit to tlaurion/heads that referenced this issue May 2, 2024
…sk Unlock Key.

Fixes linuxboot#1092.
Supersedes linuxboot#1093

- Cherry-picks ed1c23a (credit to @hardened-vault) thank you!)
- Addresses and correct self-review under linuxboot#1093 (@hardened-vault: you don't answer often here!)
  - kexec-unseal-key: Warn a user who attempts to default boot while his Disk Unlock Key passphrase fails to unseal because LUKS headers changed.
    (linuxboot#1093 (comment))
  - kexec-seal-key: Identical as in ed1c23a
  - kexec-add-key: Tell the user that the Headers did not change when changing TPM released Disk Unlock Key
    (Through changing default boot at Options->Boot Options -> Show OS boot options: select a new boot option
    and set a Disk Unlock Key in TPM, accept to modify disk and sign /boot options)
    - Here, we cancel the diff output shown on screen linuxboot#1093 (comment)
    - And we change the warning given to the user to past tense "Headers of LUKS containers to be unlocked via TPM Disk Unlock Key passphrase did not change."

Signed-off-by: Thierry Laurion <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant