Sounds like a misnomer to me.
The partition table isn’t encrypted either. What a scam.
To add to the other comments: it’s “full-disk” to distinguish it from “per-file” encryption. And “full-partition” didn’t catch on, probably because functionally an unencrypted boot partition makes little practical difference.
And also because “disk” is already too hard for most people. “Partition” would be way way too complicated a concept for most users.
I think FDE is different to full partition. If your home partition is encrypted but not your root partition, that’s not FDE. I would say FDE is when the partition that you mount to / is encrypted.
This is more nitpicking. Yes, there’s a difference between partition and disk. But if we want to get technical, it’s not disk encryption unless you’re using a HDD. SSDs don’t have disks.
At the end of the day, FDE would generally imply that all partitions with user data on them are encrypted. So it would generally include root and home partitions, and generally not include the boot partition, and would likely include partitions like /var and /opt, though not necessarily.
I didn’t mean it as nitpicking. I was just responding to you?
:I who cares… do you want it to be called system partition encryption? i mean honestly that sounds better imo but its not something that’s a big deal
Yeah, my disk’s not even full.
There is FULL disk encryption, I have it on tumbleweed with TPM and systemd boot.
This is long but further down it explains grub2 boot as luks unlocker was good , but with TPM secrets and systemd boot they can encrypt tgr ESP (EFI) partition also. TPM asks for password before unlocking bootloader.
The “disk” in this terminology is actually referring to the partition, which is the active disk when an OS boots. Different partitions are treated as different disks, it’s not about the physical disk.
Say you have 2 drives: one could contain only unencrypted portions of boot information, and the second drive could only contain encrypted partitions.
Then it would meet your definition of how it should work by terminology 😂
There is full disk encryption on Tumbleweeds using TPM and systems boot. It encrypts the ESP (EFI) partition and you supply password or fido2 key to unlock boot loader and disk
That’s not what the question is asking…
Cause there’s no user data stored on EFI, and saying “almost-full-disk-except-for-the-EFI-partition-encryption” is a bit cumbersome and, obviously, pedantic.
Sure, but unencrypted means it can be tampered with. The bootloader can be modified to write your password to disk and once you boot, submit that to a server somewhere - or worse.
That’s precisely why secure boot and TPMs exist - the TPM can store the keys to decrypt the drives and won’t give them unless the signed shim executable can be verified; the shim executable then checks the kernel images, options, and DKMS drivers’ signatures as well. If the boot partition has been tampered with, the drive won’t decrypt except by manual override.
The big problem is Microsoft controls the main secure boot certificate authority, rather than a standards body. This means that either a bad actor stealing the key or Microsoft itself could use a signed malicious binary used to exploit systems.
Still, it’s at least useful against petty theft.
TPM sniffing attacks seem possible, but it looks like the kernel uses parameter and session encryption by default to mitigate that: https://docs.kernel.org/security/tpm/tpm-security.html
There’s also PXE boot, secure boot, carrying around a live image on a flash drive, etc.
But any attacker advanced enough to tamper with your EFI partition in an evil-maid scenario has plenty of other options to log and steal your encryption passphrase, so it’s generally a moot point.
With that logic there’s no need to even encrypt your partitions 🤷
Absolutely not — the skill level needed to tamper with a bashrc, pull credentials + keys, or generally hunt for sensitive info on an unencrypted disk is worlds apart from the skill level needed to modify an EFI binary.
security isn’t real, just increasing deterrence for attackers.
if you can access something, they can access it, it’s just a matter of effort needed to get there.
wait wait. the concern here is the unencrypted partition rather than the password to the encrypted disk being known???
Must be because full-ish sounds way too much like foolish, making people think it is a useless thing to do.
Well, something has to be. You can have your EFI partition on a separate drive and then the actual drive will be fully encrypted. It’s just as good as we can get, the algorithm for decrypting the data obviously can’t be encrypted.
I think there are implementations with encryption logic stored in the BIOS or on a separate chip, but don’t quote me on that. And even then, the decryption logic itself will be unencrypted, because, as it happens, computers can’t run encrypted code.
efi partition on a separate disk makes a lot of sense actually, imo the biggest point of fde is that your boot environment doesn’t get fucked with from outside your trusted os, so if you put your efi on a read only CD or something and lock your bios to boot into that, that can’t really be tampered with easily in software
As bad as secure boot is, that’s exactly the use case for it. Frankly, you can both swap the CD and solder a new BIOS flash if you are really interested in boot poisoning, the latter is just a tiny bit harder to do without some sort of trace.
I meant software attacks, if your hardware is compromised it’s pretty much already game over unless you use something esoteric like heads maybe
Why not have the BIOS decrypt the disk then continue the boot process as normal?
Mainly because then the manufacturer decides on how your stuff is encrypted, no likie.
What do you mean?? Our Motherboards come equipped with the latest and greatest Military Grade™ MD5 RealGood™ Encryption Technology.
What do you mean it’s not longer considered secure??? Fake news, we’d never lie to you.
You are just moving things. When you change your EFI partition from being unencrypted and asking for your password to the BIOS asking for your password (or other credentials) you just shift the attack surface.
Somewhere there has to be an unencrypted part to start with.
Lock your unencrypted ESP down with secure boot and your own keys (shitty as it is that is in fact the one conceptional usecase of secure boot, not that stupid marketing bullshit MS is doing with getting vendors to pre-install Microsoft keys) to prevent tampering and you are good to go.
