On Thu, Jun 4, 2020 at 4:03 AM Marius Schwarz <fedoradev@xxxxxxxxxxxx> wrote: > > Am 03.06.20 um 07:27 schrieb Chris Murphy: > > You trust the encryption only to provide confidentiality of your data > > from the attacker. Not as a means of detecting an attack on your data. > > And also this isn't really just user data, the hibernation image is > > the kernel. If it's really compromised, it's a complete end run around > > the guarantees of Secure Boot so necessarily it can't be weaker than > > that implementation or the whole implementation is weakened. If it's > > easier to exploit via the hibernation image, that's what attackers > > will do. > > > > making an unencrypted image tamper safe by signing it, is just > unnecessary work frpm the POV of security as it stays insecure: > > a) an attacker can read the content and gain informations > b) he can change the data on disk and just wait for a reboot. > > Signing the image for the pure integrity of the data structures to be > (technically) "safe" to load > is a whole different story and a gerneral good idea. But don't mix > "safe" with "secure", it's not secure. I'm confused. No one has suggested a signed but unencrypted hibernation image. I don't see the distinction between safe and secure, these are general purpose terms. A signed but not encrypted kernel is secure insofar as if it's been tampered with, this can be detected and go to fail to avoid using a possibly corrupt or compromised kernel. To suggest that unencrypted files also aren't secure doesn't make sense. They lack confidentiality, so you can say they aren't secure from prying eyes, but it's vague to just say they aren't secure. It's better to be more specific by indicating authenticity, integrity, or confidentiality, or some combination. Also, as it relates to authenticated encrypted hibernation images, the upstream proposal is that since hibernation images can exist anywhere, they should always be encrypted independently from swap, and therefore not depend on whether swap is encrypted or how. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
