231–240 of 247 posts
Earlier quoted context omitted.
Qubes OS, the Linux distribution aspiring to offer a reasonably secure operating system, pioneering a "every app runs in a virtual machine" approach in the Linux laptop/desktop space, tracks this at the following issue: https://github.com/QubesOS/qubes-issues/issues/2890
QubesOS is Xen based. Not Linux.
Earlier quoted context omitted.
We're sort of talking about two things and conflating them. I'm sort of talking about my user experience of the system, and I'm getting it in the neck from helpdesk. Enterprise rollouts are different from anything I actually deliver, despite pushing out thousands of windows servers: I have complete control over those. Same as my local PC. But as a user on a PC I'd buy from a store, I'm not going to forget my password…
> We're sort of talking about two things and conflating them. [...] But as a user on a PC I'd buy from a store i said multiple times that i was talking about a managed fleet in an enterprise environment, and even specifically said that i dont typically recommend bitlocker for personal use, so i am not really sure what to say here. i was really clear.
I doubled down on "it's fine but not excellent" when I should have pulled away and explained that the main issues I have are about bitlocker as a user.
[flagged]
Earlier quoted context omitted.
The time limit is enforced by the TPM itself which defends against tampering.
I found some pictures of TPM modules with crystal oscillators, so those could keep time while powered on, but wouldn't be able to keep time while off. It would be possible to only count time while on, but that would be really annoying to a legitimate user that kept turning off the computer, waiting for the time limit to expire, especially if it doesn't tell the user how much time is left. Anyway, crystal oscillators…
>It's possible to change out the crystal for a higher frequency
You can't access the internals of a TPM by design.
Earlier quoted context omitted.
You need to get quite specific on actual attacks to call this insecure to be clear. Having access to the raw RAM of a machine suspended but demanding the key to resume is certainly possible but the number of attacks where you don't need this bug is "almost all of them" given at that point if the machine ever unlocks you won in this hypothetical attack even with a bug fix.
I mean, isn't the threat model here that the attacker has stolen your device? That is about the only thing full disk encryption is good for.
For example, spyware/remote-control software would open new routes to penetrate your employer's systems, or steal money from your bank account, bypassing other security measures like an additional layer of encryption on your password mode, or 2FA.
Even a relatively unsophisticated foe could connect your hard drive, dump incriminating data on it to frame you, put it back, and then call the authorities with a tip.
Earlier quoted context omitted.
You need to get quite specific on actual attacks to call this insecure to be clear. Having access to the raw RAM of a machine suspended but demanding the key to resume is certainly possible but the number of attacks where you don't need this bug is "almost all of them" given at that point if the machine ever unlocks you won in this hypothetical attack even with a bug fix.
I mean, isn't the threat model here that the attacker has stolen your device? That is about the only thing full disk encryption is good for.
Anything assuming the OS is running is already into "well that is easy" territory since if the OS is running those keys are in the same place as this attack leverages.