storing an encryption key in an EFI variable

beroal · 2021-10-15 18:40:32

I want to discuss a variation of the scenario described in “dm-crypt/System configuration”. I'm specifically interested in encrypting the root file system. To make the boot process simple, let BIOS boot a unified kernel image (as an EFI application). During boot, a hook in the initramfs in the unified kernel image should read the encryption key from the EFI variable, use it to decrypt the root file system, and continue booting from the decrypted root file system. The goal is to boot in such a way that the system administrator doesn't type in an encryption password.

The computer must boot only these unified kernel image and root file system. Otherwise, an attacker can boot their own code which will read the EFI variable. This requirement may be satisfied with Secure Boot and authenticated encryption: Secure Boot checks the authenticity of the unified kernel image, and the unified kernel image checks the authenticity of the root file system when decrypting it.

The EFI variable must be accessible only to root. Otherwise, an attacker that controls any user account on the computer will read the EFI variable through that account. This requirement may be satisfied with a modified `efivarfs` kernel module which I named `efivarfshide`. The unified kernel image mounts the EFI variable file system with `efivarfshide`. With `efivarfshide`, only root can access the EFI variable file system due to its file permissions. The source code by the link is pretty self-explanatory.

I would like to hear your critique of this approach and its vulnerabilities. I see the following vulnerabilities:

Cold boot attack. An attacker boots the computer and read data from DRAM.
Motherboard replacement attack. An attacker replaces the victim's motherboard with the attacker's motherboard. The attacker's motherboard boots the attacker's OS that shows a fake login form. When the victim types in a user password, the attacker's OS sends the password to the attacker via the internet. The victim will realize too late that they were attacked.

The security scheme where a system administrator types in an encryption password during boot is vulnerable to a motherboard replacement attack. It's also vulnerable to a cold boot attack when the computer is booted. So we don't lose to much security.

Trilby · 2021-10-15 22:12:40

Before discussing potential vulnerabilities, first, what's the point? What does this protect against. If decryption is automatic upon power up, then why encrypt at all?

beroal · 2021-10-16 11:21:13

Trilby wrote:

Before discussing potential vulnerabilities, first, what's the point? What does this protect against. If decryption is automatic upon power up, then why encrypt at all?

The root file system is automatically decrypted for the OS, but not for users ;-) . A user still needs to type in their password in order to get access to the computer, and this only gives the user their permissions, not all permissions.

Encryption protects against reading secret documents in the root file system.
Secure Boot and authentication protect from modifying the root file system unnoticeably for the victim, for example, embedding a backdoor. EvilAbigail – Automated Evil Maid Attack For Linux.

Last edited by beroal (2021-10-16 11:25:12)

Trilby · 2021-10-16 12:14:55

beroal wrote:

The root file system is automatically decrypted for the OS, but not for users ;-) . A user still needs to type in their password in order to get access to the computer

Yes, but what does this protect you from? What are the threats that could have access to the root filesystem that would not have it because of the encryption method you've implemented? This seems to be an empty set as the root filesystem is decrypted on power-up so from there on it's accessible.

beroal wrote:

Encryption protects against reading secret documents in the root file system.

No, it doesn't. Not when it is decrypted on power up.

beroal wrote:

Secure Boot and authentication protect from...

These are benefits of secure boot which is completely separate from an automatically decrypted root partition.

I can see only one possible threat mode that your strategy would protect from: if someone gets physical access to your machine and removes the hard drive and tries to put it in another system, it will not boot and the data will be accessible. But this seems silly to me as they'd effectively be going out of their way to not be able to read the data: if they have physical access to your machine, they can just turn the power on and it will boot up and automatically decrypt.

This all sounds a bit like having a very strong door and high-end lock on your house, but welding the key into the lock ... anyone can come and turn the key and come right in.

beroal · 2021-10-16 13:18:55

Trilby wrote:

What are the threats that could have access to the root filesystem that would not have it because of the encryption method you've implemented?

I'm relying on the method described in the first link in my initial post. My method is different in how the encryption key gets into the OS. The thread model is the usual one for authenticated encryption and Secure Boot.

Trilby · 2021-10-16 15:52:54

Well no, the threat model is different because your security is completely different. If the key is provided via user prompt or a flash drive or other removable key that is not in the computer itself, then there is protection against a stranger booting up the computer. That's the whole point. But with your approach there is absolutely no protection whatsoever from a stranger booting up the system as it unlocks automatically without any requirements on the person sitting in front of it.

To extend the metaphor, the key welded into the door lock on my front door has a very different (and I'm arguing non-existent) threat model than the exact same lock and door when it's assumed the person opening it must carry the key in their pocket. By changing where the key is, and making it permanent and automatic, the security provided and threat model addressed is entirely different.

Last edited by Trilby (2021-10-16 15:54:36)

beroal · 2021-10-16 16:29:19

Trilby wrote:

To extend the metaphor, the key welded into the door lock on my front door has a very different (and I'm arguing non-existent) threat model than the exact same lock and door when it's assumed the person opening it must carry the key in their pocket.

IMHO, you're confusing the notions of threat model and security scheme/protocol.

Anyway, now I see that what I'm proposing is close to storing an encryption key in a Trusted Platform Module (TPM). TPM tools for Linux became available recently, so I'll try to use them if they aren't too complicated.

beroal · 2021-10-19 06:27:46

Trilby, I'm sorry, you're right that the threat models are somewhat different. Just for reference, the usual threat model for full-disk encryption: an attacker takes a computer from a victim and wants to read data in it.

The threat model for my scheme: an attacker wants to read data in a victim's computer or spy on a victim and takes the computer from the victim, works with it, and returns it to the victim such that the victim doesn't notice it, but the attacker can't read the subsystem {CPU, main memory, EFI NVRAM} and can't return the computer with additional or modified hardware such that the victim doesn't notice it. So the attacker is unsophisticated in hardware.

sabroad · 2021-10-19 16:17:17

beroal wrote:

but the attacker can't read the subsystem {CPU, main memory, EFI NVRAM} and [...] unsophisticated in hardware.

So, protection from room-mates then?

DMA-based memory dumps can be had for <$300 -- that puts a lower-bound on the value of your data.

Trilby · 2021-10-19 19:49:22

Ok, so if I understand correctly, the only thing this would protect from is from said attacker booting the system with their own boot medium (i.e., flash drive) and then mounting and modifying data on the internal hard drive from within that live system, right?

Because they could just boot up normally, and it'd decrypt automagically just as well for them as it does for you, and they'd then have access to anything on the disk (just not the efi/nvram).

progandy · 2021-10-19 19:54:29

Trilby wrote:

Because they could just boot up normally, and it'd decrypt automagically just as well for them as it does for you, and they'd then have access to anything on the disk (just not the efi/nvram).

The way I understood beroal, there should still be the user login and linux access control in between decryption and full access. Just like the basic tpm bitlocker setup (wthout pin) windows is using these days.

Last edited by progandy (2021-10-19 19:56:15)

beroal · 2021-10-19 20:12:31

sabroad wrote:

beroal wrote:
but the attacker can't read the subsystem {CPU, main memory, EFI NVRAM} and [...] unsophisticated in hardware.
So, protection from room-mates then?
DMA-based memory dumps can be had for <$300 -- that puts a lower-bound on the value of your data.

This is discouraging :-( . So TPM is useless until we have protective cases.

P. S. I believe you meant “upper bound” instead of “lower-bound”.

beroal · 2021-10-19 20:14:38

Trilby wrote:

Ok, so if I understand correctly, the only thing this would protect from is from said attacker booting the system with their own boot medium (i.e., flash drive) and then mounting and modifying data on the internal hard drive from within that live system, right?

There is a problem in your message. If I understood it correctly, no, the attacker can't boot the computer with their boot medium because of Secure Boot (see my first post).

Trilby · 2021-10-19 20:56:37

Fine, then only a slight revision: your set up prevents them from removing the hard drive and plugging it into other hardware and booting up to some other medium and mounting / reading the drive. The main point, though, was that they can still just boot up normally and have access to whatever they want. I suppose the above-mentioned user-password could prevent some access given that they can't modify the kernel line to boot into single user mode. But all they'd really need to do is induce some failure that would make the system fall into an emergency shell and then they can do whatever they want.

Admittedly, this is not trivial, but it's also not outside the bounds of a deliberate attacker (I'm not even remotely versed in such attacks, but I'd be surprised if applying inappropriate voltage to any number of input pins couldn't reliably induce such a result). So you don't seem to get much protection from attackers, but you have a lot of inconvenience as there is no way for *you* to boot into emergency mode or single user mode to trouble shoot problems. A failure in user login can result in a bricked system it would seem.

Last edited by Trilby (2021-10-19 20:59:42)

beroal · 2021-10-19 21:50:49

Trilby wrote:

But all they'd really need to do is induce some failure that would make the system fall into an emergency shell and then they can do whatever they want.

Thank you for the remainder. The emergency shell must be disabled. I used it maybe one time in 10 years. I troubleshoot using a live boot media.

Trilby wrote:

So you don't seem to get much protection from attackers, but you have a lot of inconvenience as there is no way for *you* to boot into emergency mode or single user mode to trouble shoot problems. A failure in user login can result in a bricked system it would seem.

I would just use my live boot media registered in the Secure Boot memory (EFI NVRAM). Also I can always disable Secure Boot. Secure Boot settings and other BIOS settings must be protected with a password such that the computer boots without a password, but the settings can be changed only with the password, and the password can't be reset by removing the battery from the motherboard. For example, MSI motherboard provides this feature.

Arch Linux

#1 2021-10-15 18:40:32

storing an encryption key in an EFI variable

#2 2021-10-15 22:12:40

Re: storing an encryption key in an EFI variable

#3 2021-10-16 11:21:13

Re: storing an encryption key in an EFI variable

#4 2021-10-16 12:14:55

Re: storing an encryption key in an EFI variable

#5 2021-10-16 13:18:55

Re: storing an encryption key in an EFI variable

#6 2021-10-16 15:52:54

Re: storing an encryption key in an EFI variable

#7 2021-10-16 16:29:19

Re: storing an encryption key in an EFI variable

#8 2021-10-19 06:27:46

Re: storing an encryption key in an EFI variable

#9 2021-10-19 16:17:17

Re: storing an encryption key in an EFI variable

#10 2021-10-19 19:49:22

Re: storing an encryption key in an EFI variable

#11 2021-10-19 19:54:29

Re: storing an encryption key in an EFI variable

#12 2021-10-19 20:12:31

Re: storing an encryption key in an EFI variable

#13 2021-10-19 20:14:38

Re: storing an encryption key in an EFI variable

#14 2021-10-19 20:56:37

Re: storing an encryption key in an EFI variable

#15 2021-10-19 21:50:49

Re: storing an encryption key in an EFI variable

Board footer