Set up a new laptop for Ubuntu recently and opted for ZFS encryption, impressed it was now a mainstream install option. Sadly amused after setup that it suspends indefinitely without requiring the passphrase, ie. keeps unlocked volumes in memory. This makes the encryption basically pointless. (NB. This category of issue was highlighted in the recent interview by the resurfaced Alpha Bay operator, specifically after his former associate Cazes was bagged in Bangkok after an international police sting allegedly created a server issue explicitly to require him to log in to the so they could access his credentials unencrypted. The resurfaced operator's reported solution was apparently to always power down, even on a bathroom break.)
Authenticated Boot and Disk Encryption on Linux
171–180 of 214 posts
Re: Authenticated Boot and Disk Encryption on Linux
#172Earlier quoted context omitted.
> If your attacker is both sophisticated and able to access your hardware directly, the game is over; nothing we can do can currently avoid this. I think with blanket statements like this it's important to define sophisticated. For example, what kind of resources are required to break the disk encryption of a computer protected with tpm 2.0 + secureboot + luks w/tresor* ? I'm of course not talking about social engine…
> For example, what kind of resources are required to break the disk encryption of a computer protected with tpm 2.0 + secureboot + luks w/tresor* ? Intel ME and the equivalent AMD PSP. > I'm of course not talking about social engineering or fooling the user into typing their password on a fake system, since this is preventable. As other pointed out when the atacker has physical access it is game over. Also network a…
Again, Blanket statements.
What ME flaws?
Re: Authenticated Boot and Disk Encryption on Linux
#173Earlier quoted context omitted.
Well, you can probably annoy at least some attackers by using tamper-proof seals on your PC case and act accordingly if they are broken, because that would likely prevent them from conducting the first physical attack. But that won't help in the long run. Outstanding locks on a reinforced door and a combination of visible and hidden cameras in the hallway are probably more effective.
All tamper-evident devices can be defeated by a sophisticated attacker with physical access. https://www.slideshare.net/MichaudEric/how-to-steal-a-nuclea...
This is incorrect
Re: Authenticated Boot and Disk Encryption on Linux
#174Earlier quoted context omitted.
(slightly) slower boot time. Risk of data loss if your USB fails, more complicated backup procedures.
Yes, you should use a higher quality USB drive for this, or possibly an SLC NAND one with high write endurance. And make a backup copy or two and store them in faraday bags in a safe.
you're only going to write to the USB drive when you upgrade your kernel.
all these worries are completely overblown. I've been using USB boot method for close to 10 years now. It's just another folder/mountpoint to backup along with your normal backup.
Re: Authenticated Boot and Disk Encryption on Linux
#175Are other people experiencing too many corruption problems on encrypted disks? I have a veracrypt drive, and I regularly have to run a scan and fix on it because it's very sensitive to power cut, brutal restart, etc. Also, it's slow. I put my firefox conf folder in it, but it slows the browser down. Once I went full encrypted disk, but one day corruption happened, and it stopped booting. So I went back.
Never had a problem with LUKS over a decade of usage.
In fact, I'm actually having the opposite issue: I have a drive that is failing and LUKS is still able to decrypt it by some miracle.
> Also, it's slow.
Modern CPUs have AES instructions built-in. I would check to make sure you're utilizing them. You should not see any slowdown when using encryption.
Re: Authenticated Boot and Disk Encryption on Linux
#176If your attacker is both sophisticated and able to access your hardware directly, the game is over; nothing we can do can currently avoid this. What we can do is address the scenarios in which an attacker is either unsophisticated or remote . Normal network security takes care of the latter case, and for unsophisticated attackers, a good FDE (Full Disk Encryption) system covers it nicely. For laptops you can either l…
> If your attacker is both sophisticated and able to access your hardware directly, the game is over; nothing we can do can currently avoid this. This, particularly if your hardware has Thunderbolt capabilities. It's been proven that Thunderbolt can be exploited to give an attacker direct memory access[0], and there's really no recourse for it in the spec. Physical access is going to be game-over for a very long time…
> there's really no recourse for it in the spec
There's not only a recourse for it, modern firmware implements it. You just use the IOMMU to restrict Thunderbolt devices to being able to access their own buffers.
Re: Authenticated Boot and Disk Encryption on Linux
#177Earlier quoted context omitted.
Yes, you should use a higher quality USB drive for this, or possibly an SLC NAND one with high write endurance. And make a backup copy or two and store them in faraday bags in a safe.
you're only going to write to the USB drive when you upgrade your kernel. all these worries are completely overblown. I've been using USB boot method for close to 10 years now. It's just another folder/mountpoint to backup along with your normal backup.
Anecdote != data. And unlike the other folders, if you lose this one you lose the whole system. And it's not just writes we care about, but bit flips for any reason.
Re: Authenticated Boot and Disk Encryption on Linux
#178If your attacker is both sophisticated and able to access your hardware directly, the game is over; nothing we can do can currently avoid this. What we can do is address the scenarios in which an attacker is either unsophisticated or remote . Normal network security takes care of the latter case, and for unsophisticated attackers, a good FDE (Full Disk Encryption) system covers it nicely. For laptops you can either l…
> nothing we can do can currently avoid this.
Unless you scope "sophisticated" as "can compromise hardware we currently believe is secure", we can get to the point where the only mechanism is a hardware keylogger (which is something made far more complicated by, eg, using a Bluetooth keyboard). This has a few problems:
1) It's relatively easy to detect - you're adding a new physical object 2) You're only seeing a small amount of what you want to see - you have no ability to inspect the data on the disk, and if the user is using MFA then getting their passwords doesn't get you much 3) Exfiltrating the data isn't easy. Either you need further physical access to extract the object, or you need it to broadcast data occasionally and that's another thing that's going to make it easier to be detected
If you're able to move from "A physically present adversary can compromise the system in a way that gives them complete access" to "A physically present adversary can log your keystrokes", that's a win.
Re: Authenticated Boot and Disk Encryption on Linux
#179Every time I read stuff about secure boot, "evil maid" attack scenarios come up. And every time, they fail to mention the easiest one. The attack described here involves dismantling the victim's hard drive. I have an attack that isn't defeated by secure boot, and doesn't even require dismantling anything. Steal the original laptop. Take another physically identical unit. Replace it. Copy the login screen of original…
That's what those countless convention stickers are for, they're basically a cryptographic hash of all the leet stuff you've attended.
I can just count the missing screws on the bottom.
Re: Authenticated Boot and Disk Encryption on Linux
#180>Authentication of boot loaders is done via cryptographic signatures [...] the cryptographic certificates that may be used to validate these signatures are then signed by Microsoft This is what concerns me. While Microsoft are indeed dominant, surely them signing these is a conflict of interest? Why can't there be an external body that signs these, including those for Microsoft?
> Why can't there be an external body that signs these, including those for Microsoft?
There can be, and I strongly suspect Microsoft would prefer there to be - reviewing and signing all the UEFI drivers consumes significant resources. Nobody else with sufficient resources to do this job has stepped forward.