Defense against evil maid attack

moljac024 · 2009-12-23 12:51:02

I read this a couple of days ago, and it really defeats the purpose of a LUKS encrypted disk. What would be the best way to defend against evil maid?

1) I thought about hashing the MBR and the boot partition (and backup images as well) on the encrypted root and checking those hashes as early on in the system startup as possible, so if a change were detected, it could just restore the MBR and/or the partition and immediately reboot. Would this be some poor man's alternative to just keeping the boot partition on an USB key?

2) I would gladly boot from USB but my BIOS doesn't support it. Would it be a sound idea to flash the BIOS? I never did that, what are the potential risks?

Zariel · 2009-12-23 13:28:07

Why not store a key on a USB drive to unlock your root partition?

moljac024 · 2009-12-23 17:11:47

Zariel wrote:

Why not store a key on a USB drive to unlock your root partition?

I did, but that doesn't automagically encrypt /boot. You could just as easily obtain the key from the usb as you can obtain the password.
A million bit encryption can't help you if you have a shaky implementation.

moljac024 · 2009-12-23 23:57:31

What do you know, my BIOS does support booting from usb, I just never realised it (the usb has to be plugged in when you enter BIOS setup). Guess I don't need to flash it, hurray!

jcolinzheng · 2009-12-24 01:21:49

For many, booting from USB may be way too inconvenient. Just disable booting from non hard-drive media.

If the evil maid cannot access the internals of the laptop (ie reflash BIOS), it will be secure.

If the evil maid can access the internals of the laptop, it won't be secure *anyway*, for she can eg install a physical keylogger. Full disk encryption, and even TPM, can't help in this case.

Xyne · 2009-12-24 01:44:29

Obviously you need to run a background security check before hiring a main. Duh.

choener · 2009-12-24 02:25:47

moljac024 wrote:

Zariel wrote:
Why not store a key on a USB drive to unlock your root partition?
I did, but that doesn't automagically encrypt /boot. You could just as easily obtain the key from the usb as you can obtain the password.
A million bit encryption can't help you if you have a shaky implementation.

Why not put /boot onto that USB drive. If you carry it around anyways? Or burn yourself a CD and sign it with your name -- real signing using a pen or whatever. Pretty hard to put something on a read-only medium.

moljac024 · 2009-12-24 10:46:44

choener wrote:

moljac024 wrote:
Zariel wrote:
Why not store a key on a USB drive to unlock your root partition?
I did, but that doesn't automagically encrypt /boot. You could just as easily obtain the key from the usb as you can obtain the password.
A million bit encryption can't help you if you have a shaky implementation.
Why not put /boot onto that USB drive. If you carry it around anyways? Or burn yourself a CD and sign it with your name -- real signing using a pen or whatever. Pretty hard to put something on a read-only medium.

That's what I'm going to do. Put /boot and the key on a dedicated 512MB or 1GB USB and be done with it.

pwd · 2009-12-24 11:37:20

moljac024 wrote:

I thought about hashing the MBR and the boot partition (and backup images as well) on the encrypted root and checking those hashes as early on in the system startup as possible, so if a change were detected, it could just restore the MBR and/or the partition and immediately reboot. Would this be some poor man's alternative to just keeping the boot partition on an USB key?

Chrome OS is going to do something along these lines. I don't remember the specifics, but the functionality explained in their documentation is the same.

Edit: The details I found are somewhere in their security overview.

Last edited by pwd (2009-12-24 11:40:57)

jcolinzheng · 2009-12-24 12:22:27

moljac024 wrote:

1) I thought about hashing the MBR and the boot partition (and backup images as well) on the encrypted root and checking those hashes as early on in the system startup as possible, so if a change were detected, it could just restore the MBR and/or the partition and immediately reboot. Would this be some poor man's alternative to just keeping the boot partition on an USB key?

This can be easily duped...you can read my conversation with Joanna Rutkowska
(who coined the term Evil Maid) quoted below

> * Once the user's passphrase is recorded on the disk, the MBR code
> should restore the user's old MBR code, so that a simple MBR verifier
> which the vigilant user may run during boot will be useless.
> (Otherwise, the user gets alerted about modified MBR, and hence change
> his passphrase)
>
Correct. In fact we have implemented exactly this very idea in our Evil
Maid 2.0 that is scheduled to be published sometime at the end of this
week. It targets some other FDE software that even uses 2-factor
authentication.

P.S. Last time I checked her blog, Evil Maid 2.0 wasn't released yet. But according to her reply it's well on the way.

Last edited by jcolinzheng (2009-12-24 12:32:09)

jcolinzheng · 2009-12-24 12:29:26

pwd wrote:

moljac024 wrote:
I thought about hashing the MBR and the boot partition (and backup images as well) on the encrypted root and checking those hashes as early on in the system startup as possible, so if a change were detected, it could just restore the MBR and/or the partition and immediately reboot. Would this be some poor man's alternative to just keeping the boot partition on an USB key?
Chrome OS is going to do something along these lines. I don't remember the specifics, but the functionality explained in their documentation is the same.
Edit: The details I found are somewhere in their security overview.

There, the "verified boot" security measure doesn't seem fundamentally different from TPM. Like I said, if the adversary can open up your laptop, no security is possible in principal; if the adversary cannot, just use a BIOS password.

Xyne · 2009-12-24 12:33:38

Either you have a single USB key, in which case you're well and truly fscked if something happens to it (loss, damage, stolen), or you keep a spare somewhere, in which case you're back to square one.

While I enjoy encryption for the sake of it and advocate it as practice for when it may be needed, I would still be very hesitant to lock down my data so hard that I might lose it forever. It would have to be something sensitive and either replaceable or so sensitive that it would be better to lose it forever than let someone else get it, and then only if I thought powerful people were after it. By powerful, I mean people proficient in rubber hose cryptanalysis.

thayer · 2009-12-24 16:08:54

Xyne wrote:

While I enjoy encryption for the sake of it and advocate it as practice for when it may be needed, I would still be very hesitant to lock down my data so hard that I might lose it forever. It would have to be something sensitive and either replaceable or so sensitive that it would be better to lose it forever than let someone else get it, and then only if I thought powerful people were after it.

QFT, I couldn't have said it better than Xyne. I do use TrueCrypt virtual encrypted disks for storing portable copies of identity records (passports, etc.) and to safeguard client data, but only to thwart common thieves who might 'happen upon' my belongings.

If physical access to you or your machine is attained, anything can be gotten if the party is determined enough.

moljac024 · 2009-12-24 16:11:31

I'm already using a USB key in combination with a passphrase. So the passphrase is always there if something happens to the key. I just maybe need to make sure to type it every 10th or so boot, in order to remember it

I will move to the next step, and put the /boot partition on the usb, but will keep a backup copy of it on the encrypted root. So if something happens to the key, I could just boot from a cd or something, mount the root with the passphrase, and equip another usb with the key and /boot partition.

R00KIE · 2009-12-24 17:02:24

This is a very interesting read
I'm not using encryption yet but I plan to use it. Like others have said, it all depends on how motivated the attacker is.

If I understand correctly this attack requires full access to your machine, changing /boot requires you to reboot with a livecd/liveusb and change it, so if you use a notebook and don't long expect long power and if you were logged in, then if your machine is asking for a password to decrypt your partitions it is to be suspected.

I guess this takes care of physical access to your machine (if it is a notebook, if it is a desktop it might be easier to install a key logger between the keys and your computer) while it is left alone at work/school/whatever. In this case if you suspect your machine was compromised just boot from usb (or don't ... it might be compromised in other ways, I guess the average peep tom will be stopped either by a locked account or the encryption itself).

If you suspect your machine to be compromised while being turned off I think you have a much more serious problem, and just disk encryption and usb boot is not enough to guarantee you are safe.

Still, this is an interesting and useful problem to be aware of.

orasis · 2009-12-25 07:16:06

moljac024 wrote:

I read this a couple of days ago, and it really defeats the purpose of a LUKS encrypted disk. What would be the best way to defend against evil maid?
1) I thought about hashing the MBR and the boot partition (and backup images as well) on the encrypted root and checking those hashes as early on in the system startup as possible, so if a change were detected, it could just restore the MBR and/or the partition and immediately reboot. Would this be some poor man's alternative to just keeping the boot partition on an USB key?
2) I would gladly boot from USB but my BIOS doesn't support it. Would it be a sound idea to flash the BIOS? I never did that, what are the potential risks?

Um, sounds a little paranoid overall but if you need local security on your machine in addition to encrypted volumes than just enable your BIOS password feature.

DON'T LOSE IT.

If you have a good bios it's hard as hell to crack unless you use a weak password but even then there is no real way to brute force it anyways.

mikesd · 2009-12-25 07:52:14

Bottom line: If an attacker has physical access to your computer, it's no longer your computer. (Steve Riley)

Arch Linux

#1 2009-12-23 12:51:02

Defense against evil maid attack

#2 2009-12-23 13:28:07

Re: Defense against evil maid attack

#3 2009-12-23 17:11:47

Re: Defense against evil maid attack

#4 2009-12-23 23:57:31

Re: Defense against evil maid attack

#5 2009-12-24 01:21:49

Re: Defense against evil maid attack

#6 2009-12-24 01:44:29

Re: Defense against evil maid attack

#7 2009-12-24 02:25:47

Re: Defense against evil maid attack

#8 2009-12-24 10:46:44

Re: Defense against evil maid attack

#9 2009-12-24 11:37:20

Re: Defense against evil maid attack

#10 2009-12-24 12:22:27

Re: Defense against evil maid attack

#11 2009-12-24 12:29:26

Re: Defense against evil maid attack

#12 2009-12-24 12:33:38

Re: Defense against evil maid attack

#13 2009-12-24 16:08:54

Re: Defense against evil maid attack

#14 2009-12-24 16:11:31

Re: Defense against evil maid attack

#15 2009-12-24 17:02:24

Re: Defense against evil maid attack

#16 2009-12-25 07:16:06

Re: Defense against evil maid attack

#17 2009-12-25 07:52:14

Re: Defense against evil maid attack

Board footer