? 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
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
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
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? ).
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.