Secure hibernation (suspend to disk)

Software PureOS
1

Hi, there are different ways to power off OS in general:

  • Power off
    – wipes out RAM
    – locks all encrypted disks
  • Hibernate (suspend to disk)
    – stores RAM to disk
    – wipes out RAM
  • Sleep
    – powers off some hardware components
    – does not wipe RAM

Hibernation can use SWAP partition or SWAP file. Currently, PureOS prevents the use of hibernation with a SWAP partition as a side effect of mitigating attacks on RAM data.

I would like to achieve hibernation (suspend to disk) which is secure (does allow attacks on RAM data). It does not matter if it uses encrypted SWAP partition or SWAP file stored on encrypted disk.

Certainly it should require LUKS passphrase after each wake up. But it does not need to verify boot files with Librem Key after each wake up.

Is it possible?

Thank you

1 Like
2

Librem 14 or Librem 5?

I think this may be false. I would guess that with suspend-to-disk, it still boots from the /boot partition but then resumes from the saved state. So some files in the /boot partition would still be essential for booting (but I have no idea which files). So maybe it is still a good idea to verify the integrity of the /boot partition before resuming from suspend-to-disk.

As a fun security question … the swap file (whether partition or file) is probably not covered by the cryptographic protection given to the /boot partition (i.e. by the Librem Key). Logistically it may be easier to use a swap file - since it would then be covered by encryption of the root partition. However the default disk encryption mode may not provide true cryptographic integrity (only confidentiality) and the LUKS man page says that --integrity e.g. AEAD is “EXPERIMENTAL”.

I have my doubts that it actively seeks to clear all RAM. So RAM is vulnerable to some attacks. However it may actively clear the copy of the LUKS master key, which maybe is what you are concerned about. ?

3

I think this may be false. I would guess that with suspend-to-disk, it still boots from the /boot partition but then resumes from the saved state. So some files in the /boot partition would still be essential for booting (but I have no idea which files). So maybe it is still a good idea to verify the integrity of the /boot partition before resuming from suspend-to-disk.

It was my requirement that it does not need to verify /boot files. It could. However it could not be so helpful and feasible because:
a) integrity can be verified after next restart
b) it could give false sense of security of PureBoot if verified /boot files are rewritten or affected by malicious files stored in SWAP (attacker could find out disk passphrase), depending how RAM loading works and in what order. In a restart scenario, the knowledge of disk passphrase without ownership of the Librem Key can not affect boot verification. Of course the security of OS depends ultimately on disk passphrase always, but the argument is that the boot process which depends only on Librem Key and does not depend on disk passphrase could be compromised and it could look like it was not compromised = false sense of security of PureBoot.
c) this requires research and probably is not trivial to implement

Even without proper PureBoot after hibernation, secure hibernation is much better than sleep (locked/unlocked disk, present/wiped out RAM content).

I have my doubts that it actively seeks to clear all RAM. So RAM is vulnerable to some attacks. However it may actively clear the copy of the LUKS master key, which maybe is what you are concerned about. ?

The RAM is wiped out by cutting electricity to it. This is what power off does and this should hibernate do.

4

? But that is too late - if my supposition is correct. If files in /boot are used to resume from hibernation and you don’t verify those files before resuming then there is no need for an attacker to compromise the swap file. It would be far easier just to compromise files in /boot (since they are unencrypted).

I understand the point you are making. It would be important for the user to understand that the Librem Key is asserting the integrity of /boot and not asserting the integrity of anything else. (However it is noted that as of late last year the Pureboot process can now also assert the integrity of files in selected directories in the root file system i.e. outside of /boot.)

That does not mean that it is a bad thing to verify the integrity of /boot. Just because there are other attack vectors (in this case attacking the swap file) does not mean we should not protect against attacks on /boot.

If I understand what you are driving at, your basic question is: Can the integrity protection be extended to the swap file?

This is a question that only Purism can answer i.e. are they thinking about this? looking at it? considering it? definitely rejected it because?

The challenge there is that the swap file changes at each hibernate and hence any signature would have to be updated at each hibernate (unlike regular signatures that only need to be updated after relevant software updates).

Furthermore it could be quite slow unless a) you are not using all of RAM (typically true) and b) the signature process is aware enough of the structure of the swap file to sign only the data in the swap file that is in use. But, sure, worst case if you are prepared to wait and just sign the whole file, that can be done.

You may wish to experiment with AEAD in a crash test dummy system, which should solve the problem with attacks on the swap file. However I have no idea of the level of support for doing this. (If it works at all then you would not need to have the Pureboot process verify any files outside of /boot because the file system is permanently verifying every file outside of /boot.)

Yeah, nah. https://en.wikipedia.org/wiki/Cold_boot_attack from which

The attack relies on the data remanence property of DRAM and SRAM to retrieve memory contents that remain readable in the seconds to minutes following a power switch-off

particularly when supplemented with liquid nitrogen (Colder boot attack? :slight_smile:).

LUKS master keys should be explicitly cleared in memory during shutdown. I expect that that happens - the man page says or implies it does - but it is not something that I have verified.

1 Like
5

I would be OK with hibernation with just no electricity in RAM and no PureBoot and encrypted RAM data stored on disk. This is much better than to use sleep mode and risk random device theft.

$5 wrench attack is cheaper than cold boot attack anyway.

6

Encrypted hibernation file should already be available with Linux generally.

Be aware though that encryption (confidentiality) is not integrity. Some attacks are available against encrypted data where an attacker can alter the resulting plaintext in a controlled way without knowing what the plaintext is.

Sleeping (suspend-to-RAM) can be OK under the limited circumstances that

  • the LUKS master key is cleared from RAM before sleeping
  • no wake up ever needs to occur that is not initiated by the user (hence wouldn’t be much good on the Librem 5 where an incoming call needs to wake the phone without user action and is difficult anyway in most operating systems due to a mass of background processes that therefore need to be quiesced)
  • the user has to supply (re-enter) a LUKS passphrase in order to wake from sleep
  • the process of waking and re-opening the LUKS disk absolutely does not need any file or other data from the encrypted (part of the) disk

Both suspend-to-RAM and suspend-to-disk are useful, have their place, have their advantages and disadvantages.

I’m not familiar with that. Is that like rubber-hose decryption?

7
2 Likes
8

OK, so it is basically the same as rubber-hose decryption.

1 Like
9

Actual actual reality if somebody does care about his secrets …

  • Are you in gbay? If yes, truth drug him and just ask for the password. If that doesn’t work, forget the drugs and torture him until password revealed.
  • Is your threat model organised crime? If yes, cut fingers off one by one until password revealed.
  • Is your threat model US government (and not in gbay) or Oz government? If yes, throw in jail until password revealed.
  • Is your threat model Chinese government? If yes, throw in residential surveillance, erase all evidence that you ever existed, throw in jail on remand, torture you, kangaroo court will convict you with near certainty, you disappear.

… You can fill in the details for your own threat model / jurisdiction.

In the meantime, it is still a good idea to use disk encryption, including swap encryption, in case your device is lost or stolen, and it falls into the hands of someone who is criminal enough to attempt to use the data on the disk for bad purposes but not motivated enough to torture you or do anything else with the data once he discovers that it’s encrypted. ⇐ is probably the most likely reality.