With real full disk encryption I mean including the /boot partition like in this guide
Once this is implemented it can be combined with secure boot to make an evil-maid attack resistant install (barring firmware vulnerabilities).
Here’s relevant launchpad issue.
It’s a fairly simple change but it would do wonders for being able to verify the integrity of your install, the next step would be to implement trusted computing like coreOS.
On Windows Bitlocker does most if not all of this.
The instructions at https://help.ubuntu.com/community/ManualFullSystemEncryption/DetailedProcessPrepareInstall tell the user to download and run untrusted code from someone’s Dropbox account. I don’t think this is appropriate. If you’re concerned about an evil-maid attack, this should concern you, too.
I’m dubious about the security benefits of doing this. The bug you linked confirms that an evil maid could still compromise the ESP, therefore grub, and therefore everything else on the system.
You don’t need to download anything from dropbox if you don’t want to. Do it manually. This is also besides the point if it would be implemented by default.
I’m dubious about the security benefits of doing this. The bug you linked confirms that an evil maid could still compromise the ESP, therefore grub, and therefore everything else on the system.
What is there to be dubious about? The theoretical attack you describe is stopped by secure boot, which I specifically mentioned. You should read into topics before knocking them down, especially security.
It’s comments like these that bogged down that launchpad issue. People who don’t know much about the topic chiming in and knocking down the OP for no reason at all.
You didn’t name a single reason why it woulnd’t be a welcome change.
Secure Boot will only verify that the grub binary being executed (via shim) is the correct one. It doesn’t verify grub.cfg on the ESP hasn’t been tampered with, does it? What’s to stop me configuring grub to boot an unencrypted lookalike of your system that prompts for the passphrase, stores it (eg. to the ESP), and then chains through to an (unencrypted) Ubuntu kernel so users don’t notice?
It’s comments like these that bogged down that launchpad issue.
OK, so let’s not get into a deep security discussion here. Can you find a security expert recognised by Ubuntu developers who can confirm that this setup is actually protected via Secure Boot?
You didn’t name a single reason why it woulnd’t be a welcome change.
Because I don’t see any evidence that it’ll provide any real security benefit. Your single claim was that “it can be combined with secure boot to make an evil-maid attack resistant install (barring firmware vulnerabilities)”. I don’t see how this is true.
If I’m wrong, I’ll happily stand corrected.
I do appreciate your goal in trying to make this situation better. But when it comes to security I think you need to convince others that the technicalities are sound first.
Big breathe.
Please do some basic research. Everything you claimed can be answered by the first google result you get:
“The idea is to create a signed GRUB EFI binary which contains the required modules and base config. Secure boot verifies this binary during boot. GRUB then loads the signed grub.cfg which contains the available kernels and then loads the selected (signed) kernels and initrds. GRUB’s verification is based on GPG which is independent of Secure Boot.”
Because I don’t see any evidence that it’ll provide any real security benefit. Your single claim was that “it can be combined with secure boot to make an evil-maid attack resistant install (barring firmware vulnerabilities)”. I don’t see how this is true.
Why I have to explain this to someone arguing against full disk encryption is beyond me. You probably would have said no to the FDE we have right now with the same “arguments”. You don’t see how it’s true because you didn’t take 5 minutes to read about what secure boot is.
My first post explained that this change is specifically not enough to be resistant to evil-maid attacks. It needs Secure boot too.
But I really don’t understand how any of this is a reason to not encrypt /boot.
Please, please, please don’t just come into security discussions authoritatively when you don’t know the basics about the technologies in question. This is almost a complete repeat of the launchpad issue. Questions are fine and even welcome, but when you come in talking about how this won’t work but you don’t even know what secure boot does, something is wrong.
Please explain what problem you’re trying to solve here. In your first post you said
…so I assumed that your threat model was the evil maid and you wanted this to solve that problem for users who have and trust the Secure Boot model. From what you’ve said since it sounds like this is not the case. So please could you explain your threat model (if your goal is security related) and what you’re actually trying to achieve here? I’m not asking you to say “I want /boot encrypted”; I want you to tell us what your threat model is and how encrypting /boot will help protect you from that.
Where in the wiki instructions you linked is the user instructed to replace the trusted signed boot keys? I didn’t see that anywhere, so I assumed that you weren’t proposing to do that, unlike your new link. If you are relying on users to replace trusted signed boot keys in their BIOS by hand to be able to get a security benefit here, then how do you propose that this process be made easy for human beings installing their OS from what is supposed to be an easy to use installer? If you’re not proposing to do this, then what is the benefit of what you are proposing?
I think you need to be able to articulate the benefit of your proposal if you expect a bunch of developers to start implementing and maintaining things for you.
Secure boot and Full Disk Encryption are two independant things. Using them together can get you evil-maid resistance. I said this very clearly even in what you quoted.
The launchpad issue is about FULL DISK ENCRYPTION. So why would I link to a wiki page for secure boot? You make no sense. These are different things. Please take 5 minutes before you knock something down. Stop embarrassing yourself.
How hard is it to understand what encrypting /boot will do? It means someone won’t be able to edit your /boot and or view it.
I think you need to be able to articulate the benefit of your proposal if you expect a bunch of developers to start implementing and maintaining things for you.
Are you trolling?
I’m really done with you, this is pointless you won’t even take 5 minutes to read on what you are talking about. You said a bunch of things that were just untrue but gloss over everything and talk about “articulating the benefit”. As if you haven’t been ignoring any benefit because of your lack of threat model. You said to not implement it because according to you it doesn’t help with evil-maid resistance even when you have zero idea of what Secure Boot is or does.
But that provides no security benefit. Someone can still change your boot path entirely, causing your boot to be different - so effectively having edited /boot without needing your encryption key. And the contents of /boot is generally public (Ubuntu publishes their kernels and the initrd information there doesn’t usually leak anything confidential either) so stopping someone from viewing it is also of dubious security benefit.
Do you know what a threat model is? No security expert can take any security proposal seriously without a defined threat model, and if there’s any confusion about the threat model any security professional would find it reasonable to have that clarified by the proposer first before going any further. I’m not trolling - this is a real thing. Clearly we have confusion about your threat model. If you can’t provide clarification on what your threat model is, please don’t expect anyone to implement your proposal!
I will try to explain it from the basics, because there are so many misunderstandings. You turn on your computer -> EFI image -> grub -> initrd -> LUKS decryption->boot.
Currently there is zero guarantee that your system is not compromised even if you use Full Disk Encryption.
Where are the places that ubuntu is vulnerable?
Basically the first three steps after turning on your computer.
How can we change that?
For the first step: With secure boot you can guarantee that Everything up to and including grub is verified on boot.
But an attacker could just edit your /boot partition itself and still have a persistent rootkit on your machine.
How do we fix this? By encrypting the /boot partition and decrypt it with grub. (1)
The result? A chain of trust.
(1) An alternative here is to implement a system such as in the secure boot link I posted, where every kernel and initrd is individually signed and verified using a key in the hardware TPM (if your machine has one).
@peridot Please reign in your frustration. We enjoy open, respectful conversations here to improve Ubuntu. Personal attacks are not welcome.
Since when is wondering if someone is a troll a personal attack? or do you just automatically have to defend ubuntu devs due to your job?
A developer is engaging with you to understand and discuss the requirements and a path forward. Calling someone a troll is childish name-calling and not necessary. Yes, it’s part of my job to make sure this is a respectful place for technical discourse.
Technical discourse require both sides to be read up or else it’s just trolling one side with sophistry.
Agreed. I think you already know, but for the benefit of other observers: Ubuntu’s installer already arranges this by default when on a suitably capable system.
Agreed.
This doesn’t solve the problem. An evil maid can still replace into your ESP a valid signed grub but with a different configuration - one that boots an alternative minimal system (perhaps also stuffed into your ESP) that appears to present your normal passphrase prompt, for example, but actually sends it offline and chain loads a boot that decrypts your real system with the passphrase presented. Now you think you’re booted into a safe system, but the evil maid has your passphrase for use later.
One way to solve this would be to arrange to change the signing keys acceptable to your BIOS with custom locally generated ones. Then implement verification of the kernel, initrd and configuration being booted. That’s what your second link to different instructions appears to do. But that’s not (AFAICT) what the community wiki instructions currently do. If this were implemented instead, then the UX challenge is that it isn’t possible (intentionally and for good reason by design of Secure Boot) for the installer to automatically do the key replacement. AIUI, BIOSes differ in their UIs in how to do this, and some don’t allow it. So how will a default installer UX manage this without making it onerously difficult for its human operator?
If you are using Secure Boot they can’t, because they would have to sign the EFI with the key you control (or the vendor’s key if that is how it is set up). They can’t just load something malicious. Even if they get an old minimal configuration you yourself signed, they can’t edit it to make it exfiltrate your keys or anything.
The community wiki page is only about encrypting the /boot partition. It does not tie it all together. It’s just one person who wrote a very detailed guide of that part of it.
There’s currently no wiki page with screenshots on how to change your Secure Boot keys (not every mobo supports custom keys even), and indeed it will be a UX challenge but I think that’s a discussion for the UX/installer people mostly. If there’s a checkbox on the same page as where it asks you to use FDE offering you to use your custom secure boot key that would be fine with me.
I think encrypting the /boot partition is the lowest hanging fruit as it’s completely invisible to the user, nothing needs to be changed in the installer UX.
They can load (via shim) the stock grub EFI binary, which can be configured to boot any Linux OS (as well as others). This path will work with signing keys acceptable to the BIOS by default. That OS can do anything, including something malicious. Users typically cannot tell whether they are at a grub EFI passphrase prompt or at a malicious OS passphrase prompt (since they can be made to look identical). The malicious OS can then kexec anything, including a real Ubuntu OS. It could even pass the passphrase through so the user will not see anything different to usual.
The lowest hanging fruit that provides what security benefit?
So again. You are talking about Secure boot with the vendor keys. Of course you can load a signed (with the vendor keys) shim then. What is your point? This really seems like trolling.
The same thing has been explained like 5 times now. I’m seriously considering switching distros because this is ridiculous. This is a very simple topic. How can someone that is responsible for the security of my system have so much trouble grasping this? Either it’s trolling or you’re just plain incompetent.
For the nth time. I want evil-maid resistance. I get that by combining the proposal with Secure Boot. It’s really not difficult to understand. Holy shit.
Hi,
I have been using Linux for years but not a security expert. So not trying to be. Firstly, OpenSuSE Leap 42+ provides boot encryption as part of installation and a script to remove the requirement for the /root partition second password prompt that works by referencing a key in /etc/crypttab to a keyfile you create and then this whole thing is compiled by mikinitio and works very well.
However, I am going to be commercially deploying Kubuntu and adding them as AD clients on Zentyal.
I would prefer if /boot could be encrypted on Kubuntu same as SuSE because if the boot loader was sideways compromised my understanding is that it would not be able to call the key file any longer and so the user might report all of a sudden that the grub password prompt was no longer there (it’s a text prompt) and that a fancy “form window” had now appeared asking for a password which would be /root password which was previously being opened by grub passing it to the initramfs - and if the users were trained to notice such a small difference then they would report potential tampering.
Does this sound correct ?
Please read what @peridot says . Secure Boot is a Chain of Trust concept. Keys in UEFI are completely manageable. You can remove all vendor keys and install your own to prevent shim/windows from loading and get fully verified boot. This is the whole point of this feature.
Is there any update here? Would be interested in this as well!