On Sunday, May 31, 2020 11:45:40 AM MST Chris Murphy wrote: > 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. We do know. Nothing, really. > > > > 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 A good option until then is to just take unsigned hibernation images and work like literally every other system. There's no reason to take away this functionality. -- John M. Harris, Jr. _______________________________________________ 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
