Attack Scenarios against PGP's Whole Disk Encryption (WDE)
- From: Ulrich Windl <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 28 Apr 2008 12:45:02 +0200
Hello,
I wrote this text some time ago, and I'd like to see some comments on that:
---------------snip------------
Attack Scenarios against PGP's Whole Disk Encryption (WDE)
Basics
PGP's Whole Disk Encryption (WDE) for Microsoft Windows encrypts all the
sectors of a disk partition. When starting the system, the user is asked for a
pass phrase to unlock the system. Access to data without the pass phrase is
practically impossible, just as undetected modification of data. This is a
very good protection of sensitive data if a computer or hard disk is stolen. A
short discussion on possible attacks against that system follows. I don't know
the full details of the internals, so some things may be just speculation.
As long as standard PC hardware and BIOS is used, the boot code of the disk
partition must be unencrypted. The boot code will have to ask for a pass
phrase, verify it, and then decrypt enough of the operating system to let it
boot. In version 9.6 PGP uses the GRUB boot manager to boot the system. The
first stage of the code must be unencrypted. The second stage of the boot code
could be encrypted, but must be decrypted before it is executed.
The second stage would be responsible for displaying some screen, and decoding
the keyboard layout to query the pass phrase. It must also decide whether the
pass phrase is correct or not, because an incorrect pass phrase would most
likely decode the operating system to code that would hang or crash the
system. As WDE is implemented via a disk driver, it's unclear how the initial
portion of the operating system and essential drivers are encrypted: The
initial portion usually is loaded into RAM using BIOS mechanisms. As disk and
file system access is implemented via drivers as well, those essential drivers
must be loaded via BIOS or other legacy I/O mechanism from a simple file
system (NTFS file system access is implemented via some driver).
Attack Scenarios
The attack scenarios require physical access to the computer hardware multiple
times. This would not work if a computer is stolen, but it would work if a
computer is left unattended while being shut down.
As the first stage of the boot loader is unencrypted, that stage could be
reverse-engineered and modified on hard disk. In some trivial form, the pass
phrase being entered could be stored in some non-volatile memory, like NVRAM
or some portion of the hard disk (to be retrieved by some tool at a later
time). Possible counter-measures could be: The unencrypted portion of the boot
code is checksummed by some code inside the encrypted portion of the start-up
code. When some modification is detected, the user could be presented a
warning, the original boot code could be restored, and the user could be
prompted to change the pass phrase. That would only be effective if the
modified code did not decrypt the private key that is protected by the pass
phrase; otherwise the user would have to replace the key used to protect the
data. In one step further, the modified boot code could retrieve the symmetric
encryption key that allows full access to the partition's data. In that case,
the use would have to re-encrypt all the data with a new key.
As can be seen, a modified boot code can easily discover the secrets needed to
access the encrypted data, but it also seems rather easy to detect
unauthorized modifications of the boot code. Therefore the further
considerations deal with mechanisms how to hide boot code modifications.
If there is some space on the hard disk that can be used to put additional
data, better attacks are possible. MS-DOS compatible partition layout usually
includes some sectors that are unused. Sometimes there are unused sectors at
the end of a disk. Even if all that fails, one could just use (overwrite) a
few sectors near the end of the encrypted partition. While that would destroy
some data, it's quite unlikely that it would be detected easily or very soon.
So, what can be done? As in the initial attack scenario, the boot code could
be modified. However the new boot code would not only save the stolen pass
phrase somewhere, but it would also restore the original boot code before the
unmodified portion of the code is started. Thus the encrypted code would find
unmodified boot code. So after the first successful start-up, the modification
would be very hard to detect; only if the system would be examined before boot
(like when using a CD-ROM to boot from), the modification could be
detected. Otherwise it's very hard to find the traces of the
modifications. Counter-measures against such an attack would be booting from a
media that is never unattended, like an USB memory stick (or CD-ROM) that
contains the boot code (and maybe even the encrypted keys to access the
data). Such a media should be write-protected and never left
unattended. Modifying the encrypted portion of the hard disk could never lead
to some deterministic attack, because after decryption, the resulting code or
data would be just random bytes.
The remaining attacks would consist in modifying the hardware, firmware, or
BIOS: One could connect some key-logger device between keyboard and main
board, recording all keys being pressed, or one could modify the BIOS to
record the keys being pressed.
Conclusion
Successful attacks on WDE are possible, but they require access to the
hardware more than once. In between, the user must enter the pass phrase
without noticing that it has been stolen. If the computer is just stolen, and
a good pass phrase had been chosen, the data are most likely safe from being
disclosed or tampered. Booting from a trusted media will strongly improve the
confidentiality of the encrypted data, as only very determined professionals
will be able to modify the hardware in a way that is not noticed. The use of
wireless keyboards may greatly help attacks on the pass phrase.
Regards,
Ulrich
.
- Prev by Date: Re: GPG will not forget lost key and use a new one
- Previous by thread: comp.security.pgp.tech charter
- Index(es):
Relevant Pages
|
|
