6 ms·

Why use another encrypted partition instead of putting a swap partition/file on the same with LVM/btrfs?

by r2binx 4y ago

cbsmith 4y ago
There's a lot of security models that rely on RAM being more difficult for an attacker to access than disk (as you can imagine it is much easier to ensure things stored to disk are resistant to compromise than to ensure that nothing in working memory is usable by an attacker). Swap is that in between case where storage is memory, so that creates a unique challenge. What you want is that if someone steals your hibernated laptop, that absent a way to securely authenticate themselves as you, they can't restore the working memory of your laptop. If you think about it, if they could, much of the point of many security precautions would be lost.
- saltcured 4y ago
  I think you may have missed what was being asked? I think they assume that an LVM PV is encrypted and could contain the block filesystem and swap volumes as LVs. There is already a boot-time process to unlock such an LVM setup. Why should the swap require a separate encryption key? As a Fedora user, this is how my disks have been setup for many years, and I don't understand why Fedora have disabled hibernation. During wake from hibernation, the kernel and boot ramdisk would need user input to unlock the PV and to decode the LVs. Then, the hibernation state would be visible at the same time as the other filesystem state, and the kernel could decide whether to load the hibernation image or continue a normal boot sequence. This seems to provide the protection of content needed for theft of a hibernated machine. I don't know whether there is some unhappy sequencing flaw in the dracut-generated ramdisk (between when the wake-versus-boot decision has to be made and the LVM decryption is done), or, whether someone at Fedora has decided that the threat model is different than we discuss above?
  - cbsmith 4y ago
    > I think they assume that an LVM PV is encrypted and could contain the block filesystem and swap volumes as LVs. There is already a boot-time process to unlock such an LVM setup. Why should the swap require a separate encryption key? Again, the reason why it's different is the security model for memory is different from the filesystem. This is exactly what I was getting at: the fixed key. Encrypted swap volumes typically are set up to use ephemeral keys that are "forgotten" when you power down. The idea is that you only have access to that memory while the computer is running. When you boot up again, whatever data is in the swap partition is just noise. As mentioned in the link I provided (https://help.ubuntu.com/community/EnableHibernateWithEncryptedSwap https://help.ubuntu.com/community/EnableHibernateWithEncrypt...), the current solution is to switch to using a fixed key, much as you described. That fundamentally changes the security model, and not in a subtle way. I think there's a solution that more closely approximates the security model, with only a minor compromise: when you boot up, you generate an ephemeral key in the secure enclave, and use that to encrypt your swap. When you hibernate, the secure enclave encrypts all the metadata (including the ephemeral key) into a sealed state that is stored on disk with the swap information. When you restore, the sealed data is read back into the secure enclave (and erased) and it can then decrypt swap as needed. This still means the hibernated memory state is fully recoverable by whomever is able to authenticate with the enclave, but that's what everyone wants. On the upside, if you shut down the machine (rather than hibernate), the ephemeral key is lost, so there's no way anyone can recover what's on your swap, even if they have access to whatever fixed key(s) you have used for your LVM volumes. If you're really paranoid, you could even generate a new ephemeral key on restore and reencrypt the entire swap volume with the new ephemeral key, though I'd question what realistic threat model that would really address.
    - saltcured 4y ago
      Maybe we're not talking about the same scenarios/alternatives? If I've set up whole-disk encryption with a security level I trust for my persistent storage, how is that not appropriate for the persisted hibernation state? To me, hibernation state is a subset of persistent storage needs, not some categorically different thing. The coupling between running system and persistent state seems so strong to me that I consider them one equivalence class of data and requiring one consistent protection standard. I adopted the conveniently offered, software-based whole disk encryption mode when installing Fedora. A luks-encrypted LVM PV is the only luks mapping at runtime, and a naked /boot volume is the only volume not allocated as an LVM LV in that encrypted volume group. Thus, I have selected my storage security posture. I expect the cold or detached storage device to be resistant to inspection. Due to the unencrypted /boot, I have doubts that there is tamper-protection of the future running software, should I temporarily lose control of the physical device. I have no illusion that the running kernel lacks access to the plaintext content. My swap is an LV in that encrypted volume group. Why is hibernation disabled on Fedora? This is where I feel like there is a poorly communicated threat model or some other unstated assumption that I do not appreciate. (But see my last paragraph below for a possible answer!) Are people concerned about the written hibernation state using the same key as the filesystem volumes? I.e. that knowing how to unlock the whole-disk encryption means you can reconstruct the hibernated image too? I don't see why I, as a user, should care to protect the hibernation image even more than all my regular data. Similarly, if I have the key I can potentially attack the root volume (while offline) to inject all sorts of malware, such that I could exfiltrate RAM state from the running system in the future. Swap isn't required to open me to that attack. Are people concerned about regular swap state being available on disk during system operation? I.e. the running Linux luks mappings can be abused to inspect swap state? I am not sure I can appreciate this angle, since I think it is farfetched that the swap mapping can somehow be more resistant to attack than the filesystem mappings in the same running kernel. Are people concerned about regular swap state being left on disk during a non-hibernated shutdown? If so, I would suggest that the swap crypto should not be conflated with the hibernation crypto. Add an ephemeral cipher to swap if you must, but use framing/metadata to reliably distinguish the ephemeral swap "noise" image from a valid hibernation image. I'm OK saying that hibernate must write an entire image and not assuming that regular swapping can opportunistically prepare any hibernation state prior to a hibernation event actually commencing. While writing all this, I have thought up another possible angle. Maybe this is the actual Fedora issue? I can see that control of an offline hibernation image means control of a future running system image, and this might violate some secure boot agenda? I.e. I can tinker with the hibernated state to introduce a "hacked kernel" and ask the system to restart with that. I can see why secure boot might prevent return from hibernation. This requires some integrity-protection chain to enable the trusted bootloader and kernel to verify a hibernation image before opting to load and restart it. I can see how a variation on your "sealed state" approach could address this. But note, it only requires integrity protection and does not actually need another layer of confidentiality protection.
- r2binx 4y ago
  Ah of course, I haven't thought about it that way, thanks for your explanation. I guess it depends if you're willing to put all eggs in one basket so to speak. But instead of disabling hibernation outright maybe distros can find a compromise there. My anecdotal experience with friends that tried Linux is that it left such a bad impression when they opened they're laptop the next morning and it's lost most of its battery life that some actually went back to Windows.
  - cbsmith 4y ago
    Oddly, no one thinks about the Chromebooks.

Why use another encrypted partition instead of putting a swap partition/file on the same with LVM/btrfs?

by r2binx 4y ago

Why use another encrypted partition instead of putting a swap partition/file on the same with LVM/btrfs?

There's a lot of security models that rely on RAM being more difficult for an attacker to access than disk (as you can imagine it is much easier to ensure things stored to disk are resistant to compromise than to ensure that nothing in working memory is usable by an attacker). Swap is that in between case where storage is memory, so that creates a unique challenge. What you want is that if someone steals your hibernated laptop, that absent a way to securely authenticate themselves as you, they can't restore the working memory of your laptop. If you think about it, if they could, much of the point of many security precautions would be lost.

saltcured 4y ago
I think you may have missed what was being asked? I think they assume that an LVM PV is encrypted and could contain the block filesystem and swap volumes as LVs. There is already a boot-time process to unlock such an LVM setup. Why should the swap require a separate encryption key? As a Fedora user, this is how my disks have been setup for many years, and I don't understand why Fedora have disabled hibernation. During wake from hibernation, the kernel and boot ramdisk would need user input to unlock the PV and to decode the LVs. Then, the hibernation state would be visible at the same time as the other filesystem state, and the kernel could decide whether to load the hibernation image or continue a normal boot sequence. This seems to provide the protection of content needed for theft of a hibernated machine. I don't know whether there is some unhappy sequencing flaw in the dracut-generated ramdisk (between when the wake-versus-boot decision has to be made and the LVM decryption is done), or, whether someone at Fedora has decided that the threat model is different than we discuss above?
- cbsmith 4y ago
  > I think they assume that an LVM PV is encrypted and could contain the block filesystem and swap volumes as LVs. There is already a boot-time process to unlock such an LVM setup. Why should the swap require a separate encryption key? Again, the reason why it's different is the security model for memory is different from the filesystem. This is exactly what I was getting at: the fixed key. Encrypted swap volumes typically are set up to use ephemeral keys that are "forgotten" when you power down. The idea is that you only have access to that memory while the computer is running. When you boot up again, whatever data is in the swap partition is just noise. As mentioned in the link I provided (https://help.ubuntu.com/community/EnableHibernateWithEncryptedSwap https://help.ubuntu.com/community/EnableHibernateWithEncrypt...), the current solution is to switch to using a fixed key, much as you described. That fundamentally changes the security model, and not in a subtle way. I think there's a solution that more closely approximates the security model, with only a minor compromise: when you boot up, you generate an ephemeral key in the secure enclave, and use that to encrypt your swap. When you hibernate, the secure enclave encrypts all the metadata (including the ephemeral key) into a sealed state that is stored on disk with the swap information. When you restore, the sealed data is read back into the secure enclave (and erased) and it can then decrypt swap as needed. This still means the hibernated memory state is fully recoverable by whomever is able to authenticate with the enclave, but that's what everyone wants. On the upside, if you shut down the machine (rather than hibernate), the ephemeral key is lost, so there's no way anyone can recover what's on your swap, even if they have access to whatever fixed key(s) you have used for your LVM volumes. If you're really paranoid, you could even generate a new ephemeral key on restore and reencrypt the entire swap volume with the new ephemeral key, though I'd question what realistic threat model that would really address.
  - saltcured 4y ago
    Maybe we're not talking about the same scenarios/alternatives? If I've set up whole-disk encryption with a security level I trust for my persistent storage, how is that not appropriate for the persisted hibernation state? To me, hibernation state is a subset of persistent storage needs, not some categorically different thing. The coupling between running system and persistent state seems so strong to me that I consider them one equivalence class of data and requiring one consistent protection standard. I adopted the conveniently offered, software-based whole disk encryption mode when installing Fedora. A luks-encrypted LVM PV is the only luks mapping at runtime, and a naked /boot volume is the only volume not allocated as an LVM LV in that encrypted volume group. Thus, I have selected my storage security posture. I expect the cold or detached storage device to be resistant to inspection. Due to the unencrypted /boot, I have doubts that there is tamper-protection of the future running software, should I temporarily lose control of the physical device. I have no illusion that the running kernel lacks access to the plaintext content. My swap is an LV in that encrypted volume group. Why is hibernation disabled on Fedora? This is where I feel like there is a poorly communicated threat model or some other unstated assumption that I do not appreciate. (But see my last paragraph below for a possible answer!) Are people concerned about the written hibernation state using the same key as the filesystem volumes? I.e. that knowing how to unlock the whole-disk encryption means you can reconstruct the hibernated image too? I don't see why I, as a user, should care to protect the hibernation image even more than all my regular data. Similarly, if I have the key I can potentially attack the root volume (while offline) to inject all sorts of malware, such that I could exfiltrate RAM state from the running system in the future. Swap isn't required to open me to that attack. Are people concerned about regular swap state being available on disk during system operation? I.e. the running Linux luks mappings can be abused to inspect swap state? I am not sure I can appreciate this angle, since I think it is farfetched that the swap mapping can somehow be more resistant to attack than the filesystem mappings in the same running kernel. Are people concerned about regular swap state being left on disk during a non-hibernated shutdown? If so, I would suggest that the swap crypto should not be conflated with the hibernation crypto. Add an ephemeral cipher to swap if you must, but use framing/metadata to reliably distinguish the ephemeral swap "noise" image from a valid hibernation image. I'm OK saying that hibernate must write an entire image and not assuming that regular swapping can opportunistically prepare any hibernation state prior to a hibernation event actually commencing. While writing all this, I have thought up another possible angle. Maybe this is the actual Fedora issue? I can see that control of an offline hibernation image means control of a future running system image, and this might violate some secure boot agenda? I.e. I can tinker with the hibernated state to introduce a "hacked kernel" and ask the system to restart with that. I can see why secure boot might prevent return from hibernation. This requires some integrity-protection chain to enable the trusted bootloader and kernel to verify a hibernation image before opting to load and restart it. I can see how a variation on your "sealed state" approach could address this. But note, it only requires integrity protection and does not actually need another layer of confidentiality protection.
r2binx 4y ago
Ah of course, I haven't thought about it that way, thanks for your explanation. I guess it depends if you're willing to put all eggs in one basket so to speak. But instead of disabling hibernation outright maybe distros can find a compromise there. My anecdotal experience with friends that tried Linux is that it left such a bad impression when they opened they're laptop the next morning and it's lost most of its battery life that some actually went back to Windows.
- cbsmith 4y ago
  Oddly, no one thinks about the Chromebooks.