Prevent cold boot attacks
Andrzej Andrzej
Andrzej Andrzej
brenda...@gmail.com
> I know that it does not make much sense because SWAP is encrypted in Qubes but it could also be just in case filled it with random data. It is true that it might be too tiring to transistors in for example SSD, so it could be eg an optional option for enable somewhere in the settings.
I'm not always clear on my understanding of how much of the Qubes OS design is meant to be engineered in an anti-forensics direction vs. how much it is engineered in privacy and security direction, though the latter appears to be the focus.
That being said: one of the goals, I think, of disposable VMs is to reduce traces of activity across sessions or at least prevent security breaches from allowing adversaries to gathering intel on previous sessions. If dom0 swap itself were also encrypted at the file level ("doubly encrypted"), using a random key at each boot that is kept in RAM only, this might reduce available activity traces should there be a breach of dom0. Again, that's more in the anti-forensics domain than the security/privacy realm, of course, but they do overlap.
Just my thoughts.
Brendan
Leo Gaspard
> A good idea would be the Qubes OS feature known from Subgraph OS to prevent cold boot attacks. I saw here on the mailing list discussed about this topic but, no thread touched it in this way. I am talking about filling the RAM with random data when switching off the system. Maybe it's not something amazing but it's always an extra safety boost. Such a default option in Qubes could help protect against this attack. It is possible that this is already implemented in Qubes but I have not found any information about it on the site.
of shutting down the computer, else the RAM loses all its contents by
itself. So doing it only upon normal shutdown (ie. shutdown by the
legitimate user, as illegitimate users would just unplug the RAM without
shutting down the computer) is pointless.
I started [1] a while ago for protecting against cold boot attacks when
the computer is locked, the idea being that when the computer is locked,
secrets are put in a “hidden” box, and when unlocking the computer the
secret is pulled out of the box.
Please not that even though the API mentions a `secret`, it is there
only to be extra-safe in case of eg. a vulnerability in the
screenlocker. Even without a secret, the library should protect the
secret against cold boot attacks, assuming at least a few of the `384 *
nb_iters` are corrupted in the process of recovering the RAM.
I have been a bit behind schedule with this library, though: after
asking a cryptographer about the primitives I used, I was rightfully
pointed to the fact that I didn't need to generate all these AES keys,
and could actually just use a big random array with the data at the end
and AES-CBC-(en|de)crypt it. However, I haven't had spare time for this
rewrite yet.
HTH,
Leo
[1] https://github.com/Ekleog/hotboot/
pixel fairy
> A good idea would be the Qubes OS feature known from Subgraph OS to prevent cold boot attacks. I saw here on the mailing list discussed about this topic but, no thread touched it in this way. I am talking about filling the RAM with random data when switching off the system. Maybe it's not something amazing but it's always an extra safety boost. Such a default option in Qubes could help protect against this attack. It is possible that this is already implemented in Qubes but I have not found any information about it on the site.
theres two ways to cold boot, boot off a memory dumper, and remove the ram.
to guard against the first, set a password in your bios. then, to prevent physical tampering, seal your case with something tamper evident. my current favorite is glittery nail polish. your attacker would need a lot of prep time to fool you if your paranoid, i mean diligent, enough to bother and keep checking for it. some have suggested photography and blink tests. if you can make a portable set up for that, please tell me how!
dont bother with tapes that claim tamper proof. so far, all of them can defeated with a syringe filled with acetone. this temporarily disables the adhesive so you can do your dirty work and put it all back. ive some work in the last year on more chemically proof tapes for lab/industrial use, so there may be something work trying by the time you read this.
the second method is removing the ram. freezing it gives you more time to work, which you can do with an inverted compressed air can. the propellent comes out as a cold liquid. a friend was able to get about 15 min of usable time on this ram by doing this. the workaround is to make that ram not removable. if you have a macbook made since mid 2013 (maybe earliers?) your done. the ram is soldered in. note that, if you have a macbook, there may be other concerns depending on your threat model.
if you dont have a macbook, then you can epoxy it enough that removing the ram would break it. in the case of an attacker who only cares to get the data, they may be able to continually chisel away at it while re applying their freezing agent, and them chemically clean it off. this is, of course, a massive effort now, but someone could find (or could have already found) a more efficient method. so, keep this in mind when deciding how to seal it in. and, of course, dont thermally insulate the memory modules themselves.
aside from wiping memory on shutdown and startup, and obvious things like ephemeral swap keys (which is standard practice anyway), its silly to except the os to protect from a cold boot attack. cold booting is a side channel, and thats where you have to mitigate it.
pixel fairy
> On Thursday, July 19, 2018 at 9:00:03 AM UTC-7, Andrzej Andrzej wrote:
> > A good idea would be the Qubes OS feature known from Subgraph OS to prevent cold boot attacks. I saw here on the mailing list discussed about this topic but, no thread touched it in this way. I am talking about filling the RAM with random data when switching off the system. Maybe it's not something amazing but it's always an extra safety boost. Such a default option in Qubes could help protect against this attack. It is possible that this is already implemented in Qubes but I have not found any information about it on the site.
>
> theres two ways to cold boot, boot off a memory dumper, and remove the ram.
>
> to guard against the first, set a password in your bios. then, to prevent physical tampering, seal your case with something tamper evident. my current favorite is glittery nail polish. your attacker would need a lot of prep time to fool you if your paranoid, i mean diligent, enough to bother and keep checking for it. some have suggested photography and blink tests. if you can make a portable set up for that, please tell me how!
>
> dont bother with tapes that claim tamper proof. so far, all of them can defeated with a syringe filled with acetone. this temporarily disables the adhesive so you can do your dirty work and put it all back. ive some work in the last year on more chemically proof tapes for lab/industrial use, so there may be something work trying by the time you read this.
i meant to say ive *seen* some work in this. i dont work in that industry. also, i should have been more clear about the threat model. sealing it is to prevent the evil maid from disabling whatever bios protection you put in place so she can cold boot you later.