DDI: Add recomendation for LUKS encrypted partitions #164
Conversation
specs/discoverable_disk_image.md
Outdated
| The [DPS](discoverable_partitions_specification.md) defines the GUIDs to use and the format of the | ||
| `dm-verity` signature partition's JSON content. | ||
| `dm-verity` signature partition's JSON content. The [DPS](discoverable_partitions_specification.md) | ||
| allows optional `LUKS` encryption for additional confidentiality. Note that `LUKS` encryption alone does not |
There was a problem hiding this comment.
LUKS is written as plain LUKS not LUKS in the other specs, so that should be done here as well for consistency.
There was a problem hiding this comment.
thanks for your review, done!
frederictobiasc
force-pushed
the
main
branch
2 times, most recently
from
8664728 to
70893f1
Compare
| `dm-verity` signature partition's JSON content. The [DPS](discoverable_partitions_specification.md) | ||
| allows optional LUKS encryption for additional confidentiality. Note that LUKS encryption alone does not | ||
| provide authentication or integrity protection. A LUKS encrypted partition shall be protected by signed | ||
| `dm-verity`. |
There was a problem hiding this comment.
Is there anything actually implementing building such images? And how do they get around the problem of the LUKS header being updated and invalidating the verity hashes?
There was a problem hiding this comment.
Is there anything actually implementing building such images?
Not a one-stop shop. I currently create them by a script that makes use of veritysetup + cryptsetup.
I guess the right place to implement that would be systemd-repart. repart currently only supports creating DDIs with verity protection.
And how do they get around the problem of the LUKS header being updated and invalidating the verity hashes?
In this case, LUKS operates on the read-only target provided by dm-verity. Consequently, there is no way for LUKS to update any headers.
There was a problem hiding this comment.
Not a one-stop shop. I currently create them by a script that makes use of veritysetup + cryptsetup.
Before being added to a specification there should be at least one common implementation
There was a problem hiding this comment.
What would be the right thing to do? Reopen or put it on draft until the repart implementation is done?
specs/discoverable_disk_image.md
Outdated
| allows optional LUKS encryption for additional confidentiality. Note that LUKS encryption alone does not | ||
| provide authentication or integrity protection. A LUKS encrypted partition shall be protected by signed |
There was a problem hiding this comment.
Is this true though? AEAD is supported in LUKS2 (though experimental) and that does provide integrity and authentication?
There was a problem hiding this comment.
A LUKS encrypted partition shall be protected by signed
fwiw, do we care about RFC2119? "shall" denotes an absolute requirement and that seems like a strong word?
There was a problem hiding this comment.
I added a reference to LUKS2 AE as a footnote, as it's still experimental.
frederictobiasc
force-pushed
the
main
branch
from
70893f1 to
b94091e
Compare
Add note clarifying LUKS encryption vs dm-verity protection to inform users not to confuse confidentiality with integrity and authenticity. Addresses systemd/systemd#38854 (comment)
frederictobiasc
force-pushed
the
main
branch
from
b94091e to
7373883
Compare
|
so thing about the combination of dm-crypt + dm-verity is that right now the most prominent implementations of DDIs, i.e. systemd's, doesn't support it. I am always reluctant to merge specs without code somewhere that implements it. After all, I am not entirely sure which of the two should be on top of the other, and my guess is thta we'd learn once we actually implement this. (my guess is dm-verity should envelope dm-crypt, not vice versa) |
Add note clarifying LUKS encryption vs dm-verity protection to inform users not to confuse confidentiality with integrity and authenticity.
Addresses systemd/systemd#38854 (comment)