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
