Does FreeBSD do a better job addressing the issues he raises?
Authenticated Boot and Disk Encryption on Linux
161–170 of 214 posts
Re: Authenticated Boot and Disk Encryption on Linux
#162Earlier quoted context omitted.
GP already made space for this analysis by admitting a sophisticated/unsophisticated axis, thus the contrary stance of your comment is unnecessary. You don't really make an argument on where your example should fall on that axis, which is what I would have preferred to see.
I think it's a fair doubt. In this case, I don't know if sophistication could mean an evil maid attack with a breadboard and $15 worth of electronic components (which was required to break the tpm 1), or something better than what the FBI has since they struggled to unlock a terrorist's phone. I can worry about the former, and relax about the later. I'm not an expert and when someone throws that statement with author…
It's certainly possible to MITM a TPM, this is why MS built all the keys into the CPU on the Xbox One[1].
[1] https://www.platformsecuritysummit.com/2019/speaker/chen/
Re: Authenticated Boot and Disk Encryption on Linux
#163>Unfortunately not at all. Because distributions set up disk encryption the way they do, and only bind it to a user password, an attacker can easily duplicate the disk, and then attempt to brute force your password.
I think this "not at all" is a bit strong. With a good enough passphrase and a slow key derivation algorithm bruteforcing the key should be impossible in practice.
The key derivation takes about 2s for my root partition for instance, fast enough that it really doesn't make a difference for a legitimate user but slow enough to be hugely impractical to bruteforce, especially given that I use a long, random passphrase.
On the other hand the author is entirely right that this setup is rather simple to backdoor for a sophisticated attacker, but it does a good job of protecting the data at rest.
Re: Authenticated Boot and Disk Encryption on Linux
#164Earlier quoted context omitted.
Almost all UEFI firmware allows replacing the default public keys with your own, and then you can sign everything yourself with private keys only you possess.
In theory. But part of the UEFI boot chain is Optional ROM files stored on hardware. Most commonly found on dedicated graphics cards and other hardware. All of these files need to be authenticated, and currently signed by Microsoft or the OEM vendor. A modern Lenovo Thinkpad T14 Gen 2 laptop has 7 OpROM files. If validation fails for the GFX card you are essentially "soft bricking" the device since the GFX card won't…
I completely replace the entire set of secure boot keys with my own (no MS keys at all)
for my desktop PC I had to sign the graphics card option ROM digest myself (which was a pain)
however for my Thinkpad none of this was necessary as the firmware was stored inside the UEFI image
Re: Authenticated Boot and Disk Encryption on Linux
#165Earlier quoted context omitted.
You probably have some fun disk caching turned on in the OS or your disk has a built in cache that it’s not properly flushing. I’ve seen this before with cheap SSDs.
Maybe, I don't know enough about this, but I've been using this veracrypt disk on 6 machines, now, and I have the problem with each of them. Also, I don't have any problem with non encrypted data.
Looks like a veracrypt problem then.
Re: Authenticated Boot and Disk Encryption on Linux
#166Earlier quoted context omitted.
Or encrypt the boot partition. Libreboot supports this. (Though to be fair, Libreboot only runs on a very limited number of old devices).
No amount of software complexity defeats a hardware keylogger, though... or like, a no-touch version of that, such as a spycam in the room that records the sight and sound of you typing your password.
Security token defeats all that.
Re: Authenticated Boot and Disk Encryption on Linux
#167Earlier quoted context omitted.
> LUKS leaves encryption metadata unencrypted. Except for ruling out plausible deniability, what problem does this pose?
Metadata includes file names. If you have a file on your computer called proof_nsa_is_doing_illegal_stuff.pdf, that would significantly help a prosecutor trying to convict a wistleblower even if they can't get the file.
No it doesn't. LUKS encrypts a block device, and then the filesystem is instantiated on that encrypted block device. No file names are visible.
Re: Authenticated Boot and Disk Encryption on Linux
#168If 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, unfortunately.
Re: Authenticated Boot and Disk Encryption on Linux
#169Earlier quoted context omitted.
> This way the big disk can have full, real FDE (not LUKS). I thought LUKS was the only way to do FDE in Linux. What other options for FDE are there? But yes, putting /boot on an external USB drive is the only way I know of get FDE on your hard drives. Possible with UEFI, not BIOS/MBR.
LUKS leaves encryption metadata unencrypted. For real FDE, use "plain dm-crypt" with cryptsetup: https://security.stackexchange.com/questions/109223/what-doe... > Possible with UEFI, not BIOS/MBR. Why do you think that? I have this setup on a modern (UEFI) computer, but I use the old BIOS/MBR interface.
> LUKS leaves encryption metadata unencrypted.
You can detach the header and store it on a USB drive, and boot from the USB drive. No one will know you're using LUKS at that point.
Re: Authenticated Boot and Disk Encryption on Linux
#170Does FreeBSD do a better job addressing the issues he raises?
I did not read the article but the FreeBSD bsdinstall(8) installer gives you the option to use the GELI full disk encryption with ZFS on top of it.
Its kinda similar to LUKS on Linux and will ask you for password in the bootloader.
Here are the details:
https://docs.freebsd.org/en/books/handbook/disks/#disks-encr...
Regards.