Full disk encryption bypass on systems using TPM #7
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
On systems using a TPM2 to unlock their LUKS partition, an attack detailed in this blog can be done to decrypt the disk.
Also, there is not a lot of documentation regarding the PCRs to use, this guide can help, and this issue on systemd is talking about this problem.
I find the fact that we can use the PCR15 in
systemd-cryptenrollsuch as :without having any warning that the PCR15 is not measuring anything by default (crypttab(5), section tpm2-measure-pcr=) is a problem.
warning : the PCRs values used above should not be considered as a security best practice, it is not heavily tested.
Can we do anything to help with this ?
Maybe by enabling
tpm2-measure-pcr=yesby default ?Summing up the discussion, I think this should be tackled upstream: a reasonable next stage seems to be https://github.com/systemd/systemd/issues/37051 , and it was already labelled by the upstream systemd maintainer with tpm2, so it was not dismissed or so. Further relations to other upstream projects might occur too (if not already there).
PCR15 seems to have many implications, and it might corrupt much expected default behavior and documentation for users if we would change that on the OS level rather then upstream. Implications over time are hard to foresee if we change that one-sided without upstream. Also, at least default use cases of Fedora should not be vulnerable in practice given the requirements of the attack.
The related teams on our side are primarily
storagedand (Fedora)systemd, both have a strong tendency to emphasize on upstream (for the elaborated and further reasons). I expect them to also prefer this to be solved upstream, especially as the impact of the mitigation might bring comparable if not more issues than it solves if done on our level.anacondais indirectly related, but they already emphasize a core user group without tpm2 because they are at their limits and have limited resources. tpm2 seems not on their scope at all atm, which might also further decrease incentives for other teams to make local changes compared to upstream.That said, I think it would be useful to follow this case upstream, follow when/where/how it develops, and once changes/updates end up on Fedora in testing, we can help to test these tools: on one hand, to get them pushed to stable more quickly. On the other hand, to ensure that the functions this is about are properly tested: e.g., if a new systemd is ending up in Fedora but no one tests the mitigation of this specific case (may it be with or without PCR15), we might miss bugs that risk the security (may it be security of confidentiality or of availability).
So my suggestion would be to keep the ticket open, keep following/monitoring upstream and keep the ticket updated (maybe also with the other related links we discussed in the chat to document/link the contexts and keep the relations/outreach connected and monitored), and see when something arrives on Fedora to test it properly and provide (bug) reports/feedback if applicable. But the task to keep it updated would be necessary to be done by others. I currently try to avoid further obligations for time reasons :(
Another means, for those who want to invest time, might be to not just follow upstream, but also reproduce/test what is discussed there and provide feedback to their discussions early.
Hope that makes sense? Other ideas?