On Sat, May 30, 2020 at 9:26 PM Tony Nelson <tonynelson@xxxxxxxxxxxxxxxxx> wrote: > > On 20-05-30 21:02:11, Chris Murphy wrote: > ... > > Full disk encryption doesn't adequately secure the hibernation image > > either. Authenticated encryption (signing as well as encryption) is > > needed to verify the image hasn't been tampered. > > What can an attacker do other than corrupt the data? It is encrypted. You don't know, and neither do I. That's the problem. > With tamper detection, does a single bit changed deny the use of the > hibernated image? I expect so. Even at a far lesser level of integrity, e.g. non-crypto crc32c used by dm-integrity and Btrfs by default, a single bit flip is detected and you get EIO on reads. > In either case, what can an attacker accomplish? I have the same question, exposing me as (a) not a very good attacker, and (b) not a cryptographer. Nevertheless I'm persuaded by the argument that if I've signed up for signature verification of the kernel and kernel modules at the start (UEFI Secure Boot), that it's a bad idea to enable a loop hole where unauthenticated data is executed. It doesn't matter if it's encrypted. It provides no error detection mechanism. Such a loop hole in effect is an attack on the Secure Boot paradigm. And for now it's a difficult problem with limited resources committed to resolving it. There are other ways to go about it, that also aren't exactly easy but they might turn out to be more viable than AE hibernation images. > > The upstream work, cited in the document, gets into the details, > > and what additional work is needed for the next revision. > > Which reference is that? #5? It seemed short. I only provided a link to the most recent status. You need to click on that link to get to the lkml email, and click on the link in there too, and follow it to the patch set and ~18 email discussion. It's short because it needs more work and the developer hasn't found enough time to get back into it yet. -- 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
