On Tue, 2020-06-02 at 21:58 -0700, John M. Harris Jr wrote: > On Tuesday, June 2, 2020 9:45:45 PM MST Chris Murphy wrote: > > On Tue, Jun 2, 2020 at 10:28 PM Samuel Sieb <samuel@xxxxxxxx> wrote: > > > > > > > > I would expect that using an encrypted partition for swap should be > > > sufficient to allow it though. > > > > Unfortunately not. Encryption provides no integrity or authenticity. > > The original set of patches for signed and authenticated hibernation > > images called for the use of an HMAC for signing, and upstream > > considered this insufficient and asked why not use AES-GCM to provide > > a real AE (authenticated encryption) model. > > In what way do you believe it's not sufficient? AES GCM Is generally *not* a good algorithm for disk encryption so I am not sure why this is being brought up, HMAC is sufficient to verify integrity. In any case the problem is that adding integrity protection cannot be done w/o losing some space on the disk, as you need to save the integrity tag/hmac. As to why just encryption is not sufficient that is because you can easily play a number of replay attacks, corruption attacks, and potentially even sectors-wap attacks with naive encryption schemes. This can be sufficient to generate an attack vector in certain circumstance once the machine boots up again. (As an hypotetical if the attacker is able to observe which sector contains the passwd file and can corrupt it or replace it with other content that effectively gives it access with a known secret or a blank password or whatnot, or maybe it can create corruption in the kernel in such a way that it causes the machine to display a OOM that reveals encryption keys, or... the possibilities are endless). > > Not only is encryption alone inadequate, the signature verification > > model should ensure that the hibernation image being restored was > > created by the computer it is being restored to. > > Why? Evil maid attacks. Because without a signature you could replace the whole image with a completely functional one that you fully control. Boot the system with a hybernation image generated on identical hardware but with your own data, give your own decryption key, presto, as soon as the hybernation image is restored the system is running your image. From there you could be able to use, for example, keys stored in the TPM or simply you capture the real password for the real image as soon as the user returns to the machine to unlock it and transmit it, and now you have access to the original disk image and all its contents... Again, possibilities abound. > > I am not a cryptographer. And I can't do a better job of explaining > > it. But it's a problem. And my disappointment isn't relevant to the > > security issue. It's relevant from a UX perspective I suppose. > > It's a severe UX issue that you cannot use a standard feature of normal > systems, hibernation. A way to deal with hybernation o secure boot would be to *measure* the hybernated image as the last action of hybernation and store the measure in TPM. Fail to restore on boot if the TPM fails to check the measured image. (Measure here effectively ends up being running an HMAC on the whole disk image you want to restore and storing the results in TPM). > > But, I've also just spent two days trying to track down a new > > hibernation bug, resulting in fatal hibernation entry. Even without > > the Secure Boot issue, hibernation can be a problem that requires > > resources that are not finite. I had this working reliably several > > months ago, and I've exhausted my time and interest for now doing > > kernel regression testing and have literally no idea why it's > > consistently failing now. On three machines (one is a VM). I did > > report it upstream, I haven't gotten a reply yet (normal). > > > > There are two emails, bottom one is the first. > > https://lore.kernel.org/linux-pm/CAJCQCtQVGqxtZZTRgscT7e4inTacAd7KAmoNOz3gB4 > > Hf1Nkp0w@xxxxxxxxxxxxxx/ > > > -- > > Chris Murphy > > -- > 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 -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ 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
