On Wednesday, June 3, 2020 12:06:19 PM MST Simo Sorce wrote: > 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. I was asking why encryption itself would not be sufficient, nothing to do with AES-GCM, just to clarify. > 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). All of these are possible through many other methods, but all of these require physical access. Once you're talking about physical access, the threat model changes entirely. > > > 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. This sounds like legitimate functionality that may be desired. Am I wrong? > 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). The larger UX issue is that hibernation is disabled for ALL users just because it doesn't work for users with Secure Boot, which are probably a minority when it comes to those running Fedora, CentOS or RHEL, and I'm saying this as a CentOS/RHEL sysadmin and Fedora user. I'd like to see some data on that before saying for sure, of course. > > > 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/CAJCQCtQVGqxtZZTRgscT7e4inTacAd7KAmoNOz > > > 3gB4 Hf1Nkp0w@xxxxxxxxxxxxxx/ -- 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
