Re: Supporting hibernation in Workstation ed., draft 1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 2, 2020 at 10:35 PM Samuel Sieb <samuel@xxxxxxxx> wrote:
>
> On 6/2/20 9:25 PM, Chris Murphy wrote:
> > On Tue, Jun 2, 2020 at 8:33 PM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> wrote:
> >>
> >> 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.
> >
> > You do not know the attacker, when possession was lost, what the
> > attacker knows, or how long they have access to ciphertext. And that's
> > because the attack hasn't happened yet. Yet you assert omniscience.
> > Gotcha.
>
> I don't understand this concern either.  How is it different than any
> encrypted filesystem?  If you don't trust the encryption, then what's
> the point?  What's the difference between an encrypted filesystem and an
> encrypted hibernation image that makes the image so insecure?

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.

An encrypted file system, again provides only confidentiality. There's
no integrity check. In fact you are equally susceptible to data
integrity problems whether your data is encrypted or not. You'd need a
dm-integrity option enabled (an option that can be done at the same
time as cryptsetup now), or you need to use Btrfs. Depending on your
threat model you might need to use one of the cyptographic hash
functions (dm-integrity provides hmac:sha256; and btrfs provides
sha256 and blake2b, looks like keyed hashing support is decently
likely to happen there as well). The keyed hashing function provides
integrity but also provides authenticity. You need the key to produce
valid writes. If you don't have the key, the writes you produce would
be immediately detected as bogus by the key holder.

Ergo you can trust your attacker can't see in /usr. But you don't
know, with encryption alone if you can trust /usr. It pretty much
comes down to trusting the hardware ECC in the drive, if you don't
have something that provides integrity.

-- 
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux