Re: [qubes-users] Activating FDE on lid close
On Fri, Nov 01, 2019 at 07:38:53AM +0100, tetrahedra via qubes-users wrote: The original scenario is that the user shuts the laptop lid knowing that an adversary is about to take control of the machine. In this case, an evil maid attack is not really an issue... by the time the user gets the laptop back, the old infosec adage "nuke it from orbit, it's the only way to be sure" is liable to apply. It looks like someone has figured out how to encrypt the laptop on lid suspend, which is fairly close to the original goal: https://github.com/QubesOS/qubes-issues/issues/2890 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191208032843.GA1049%40danwin1210.me.
Re: [qubes-users] Activating FDE on lid close
On Thu, Oct 31, 2019 at 11:47:31AM +, Claudia wrote: There is also the possibility of a physical attacker booting their own OS that pretends to be your FDE lock prompt as a way to steal your passphrase. This all depends on the scenario. Specifically, it assumes an evil maid attack, where the machine is compromised and then used by the rightful user again. There are other scenarios where the idea would be useful. Consider if your suspended laptop is just simply stolen by your local county police (who don't know how to mount a real evil maid attack but can perform a cold boot attack). There's a big difference between the key being in RAM or not. The original scenario is that the user shuts the laptop lid knowing that an adversary is about to take control of the machine. In this case, an evil maid attack is not really an issue... by the time the user gets the laptop back, the old infosec adage "nuke it from orbit, it's the only way to be sure" is liable to apply. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191101063853.GA2577%40danwin1210.me.
Re: [qubes-users] Activating FDE on lid close
Chris Laprise: On 10/24/19 9:17 AM, tetrahedra via qubes-users wrote: From Ratliff's "The Mastermind": "...they were told to close the computer immediately. The TrueCrypt software would be activated as soon as the laptop lid was shut." While most Qubes users are probably not interested in starting global criminal empires, this specific idea seems useful enough. Currently there is no option in Xfce Power Manager to shut down the laptop entirely, and "hibernate" is not supported by Xen. Is there another way to ensure FDE gets fully enabled when the laptop lid is shut? IIRC past discussion about this hinged on the feasibility of cold boot attacks. Since the contents of RAM was recoverable, protecting the disk this way was not seen as important. That really depends on what we're talking about when we say "activate FDE." If you're talking about a simple shutdown/poweroff, then yes, usually RAM, including the key, is recoverable for some minutes. But if you wipe the key first, or you reboot instead of shutting down (memory is zeroed at boot), then the key can't be recovered by a simple cold-boot attack. That's my understanding at least. If you want to protect valuable secrets from cold boot, you'd have to shut down sensitive VMs before activating the FDE lock... at that point, you're not very far from the level of effort required to boot the whole system. There is also the possibility of a physical attacker booting their own OS that pretends to be your FDE lock prompt as a way to steal your passphrase. This all depends on the scenario. Specifically, it assumes an evil maid attack, where the machine is compromised and then used by the rightful user again. There are other scenarios where the idea would be useful. Consider if your suspended laptop is just simply stolen by your local county police (who don't know how to mount a real evil maid attack but can perform a cold boot attack). There's a big difference between the key being in RAM or not. I think a case could be made for an FDE lock + hibernate in some use cases, however. If we consider computers that have secured boot code which resists replacement and is tamper-evident, then it might be worth pursuing. Again, depends on the scenario. I don't think hibernate vs suspend makes much difference in theory though (see below). BTW, I'm not aware of a Linux FDE lock. Are you? Not sure what a "Linux FDE lock" is per se. By FDE, I'm assuming we're talking about dm-crypt or perhaps veracrypt. The "lock" part has me a little confused. Anyway, here's what I'm ultimately getting at. Dm-crypt has a feature/command called "luksSuspend" which "suspends active device (all IO operations are frozen) and wipes encryption key from kernel." In theory, luksSuspend could be invoked when the lid is closed, before the system goes to sleep. When the system is resumed, a program* would need to prompt for a password, but without touching the filesystem (or it would block indefinitely because all I/Os are frozen). The kernel can't load the program itself from disk either, so it would have to be already running in RAM before luksSuspend. Most likely the same program would do the whole luksSuspend, password prompt, luksResume operation. *: Is said program what you're referring to as "Linux FDE lock"? I don't know if any such program exists, but in theory I don't think it would be that difficult. The hardest part would probably be getting the prompt to display in the graphical session without the program being invoked from the user's session (e.g., if it is invoked by system suspend/resume hooks). I actually thought about trying to write something like this for Archlinux several years ago, but never got around to it. Also note that this is independent of system suspend. You could probably patch the XFCE/KDE/Gnome/whatever lockscreen to behave this way, such that anytime the screen is locked (whether due to inactivity, sleep, or hotkey), it calls luksSuspend, and anytime it is unlocked, it passes the typed password to luksResume. Alas, however, I can't help but think, if it were that easy, then it would have been done by now. Just my take. I could be wrong though. - This free account was provided by VFEmail.net - report spam to ab...@vfemail.net ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1aa58649-85de-fdf6-a970-86bb48bd406f%40vfemail.net.
Re: [qubes-users] Activating FDE on lid close
On 10/24/19 9:17 AM, tetrahedra via qubes-users wrote: From Ratliff's "The Mastermind": "...they were told to close the computer immediately. The TrueCrypt software would be activated as soon as the laptop lid was shut." While most Qubes users are probably not interested in starting global criminal empires, this specific idea seems useful enough. Currently there is no option in Xfce Power Manager to shut down the laptop entirely, and "hibernate" is not supported by Xen. Is there another way to ensure FDE gets fully enabled when the laptop lid is shut? IIRC past discussion about this hinged on the feasibility of cold boot attacks. Since the contents of RAM was recoverable, protecting the disk this way was not seen as important. If you want to protect valuable secrets from cold boot, you'd have to shut down sensitive VMs before activating the FDE lock... at that point, you're not very far from the level of effort required to boot the whole system. There is also the possibility of a physical attacker booting their own OS that pretends to be your FDE lock prompt as a way to steal your passphrase. I think a case could be made for an FDE lock + hibernate in some use cases, however. If we consider computers that have secured boot code which resists replacement and is tamper-evident, then it might be worth pursuing. BTW, I'm not aware of a Linux FDE lock. Are you? Re: Xfce... You'll find the power options in KDE to be more complete and functional. For example, the system shutdown option is available and may also be triggered with a keyboard shortcut. Monitor power save mode also works correctly with KDE on various systems but in Xfce it usually doesn't. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/51153f1c-b574-6686-fda4-fd7384bbaa13%40posteo.net.
[qubes-users] Activating FDE on lid close
From Ratliff's "The Mastermind": "...they were told to close the computer immediately. The TrueCrypt software would be activated as soon as the laptop lid was shut." While most Qubes users are probably not interested in starting global criminal empires, this specific idea seems useful enough. Currently there is no option in Xfce Power Manager to shut down the laptop entirely, and "hibernate" is not supported by Xen. Is there another way to ensure FDE gets fully enabled when the laptop lid is shut? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20191024131738.GA6294%40danwin1210.me.
