mailing list archives
Re: Laptop - Full Disk Encryption? (Booting defeats FDE)
From: Ansgar -59cobalt- Wiechers <bugtraq () planetcobalt net>
Date: Thu, 6 Dec 2007 21:49:41 +0100
On 2007-12-06 Tim A. wrote:
Ansgar -59cobalt- Wiechers wrote:
On 2007-12-06 Tim A. wrote:
Run a Virtual Machine inside a TrueCrypt volume.
The VM cannot even be opened until the TrueCrypt volume is mounted.
*Everything* is encrypted, paging file / swap file, OS and User
right down to your CMOS and boot blocks.
How will it preform? Good question. Give it a shot.
Performance issues aside, an attacker will still be able to
manipulate the host operating system, which in turn will be able to
manipulate the guest operating system once the VM is started. Virtual
Machines are designed to protect the host OS from the guest OS, *not*
Yes, but disk encryption is not about intrusion prevention. That's a
Depends on your definition of "intrusion prevention". Disk or partition
encryption does protect an operating system as long as it isn't running.
That way an attacker can't tamper with the OS by booting e.g. from CD.
If you were running an OS on an encrypted disk, the encrypted disk
does not make the processes of the OS any more secure than if the disk
were not encrypted. The OSs vulnerabilities are still vulnerable, the
disk encryption does not help in that regard.
Protection of a running system is a different beast, indeed. However,
encryption is generally not suitable for protecting a live system.
Encryption has the purpose of protecting a system while it is not
running (because then the kernel can't enforce anything).
Disk encryption is more about mitigation. Just dismount the volume and
capture is moot to the guest, other than being offline (obviously).
It's data is safe, or at least all the data that was not yet captured
before the plug was pulled.
Again, disk encryption can do more than that. It protects the data, but
it also protects the operating system itself. How are you going to
tamper with libraries or even the kernel, when you can't access them
because disk or partition are encrypted.
Of course there are additional attack vectors (e.g. modifying the BIOS),
but disk encryption does prevent direct manipulations of the operating
I'm thinking of it more as a computer with a BIOS password that cannot
be blanked out, locked in a room that when the door is closed cannot
be opened except by the owner.
In case of a BIOS password an attacker could still attach the harddisk
to some other system, and thus still tamper with the operating system.
Disk encryption still protects OS and data, even if an attacker extracts
the harddisk from the original system.
It's still a computer, and while the door is open and the computer is
on it's still vulnerable and always will be.
Yes. So? Disk encryption addresses some issues and doesn't address
others. Just like filesystem permissions or firewalls address some
issues while not addressing others.
Not saying it's perfect. Nothing is.
Nobody claimed that.
What's your point, anyway? That there's no silver bullet? Well, duh. We
all know that already. When you develop your security concept you
identify the attack scenarios your systems may be exposed to, and then
try to find ways to inhibit the attack vectors. Of course sandboxing
processes in a VM may help protecting the host OS from some attack
vectors. However, I fail to see how *encrypting* a virtual machine while
leaving the host system unencrypted is supposed to mitigate anything
that disk encryption wouldn't.
"All vulnerabilities deserve a public fear period prior to patches
--Jason Coombs on Bugtraq