[CipherShed Devs] two-factor pre-boot-authentication with USB stick and password

FN fne at alice-dsl.net
Tue Jul 29 05:41:48 CST 2014


Maybe you are interested in my patch against TrueCrypt 7.1a for a
two-factor-authentication at boot time (description see below).

Some years ago I tried to contact the TrueCrypt developers to provide
the patch for the next release. Unfortunately I never got any feedback.
Hence I decided to publish the patch in the TrueCrypt forum. Since the
forum is not available any more, I offer the patch together with text in
the forum at that time to you (see below).
I personally use the patched version on my laptop for a long time
without any problems.

Although I have no spare time at the moment, I'm still thinking about an
implementation of an UEFI based TrueCrypt boot loader with GPT support
for the OS partition encryption. This is, in my opinion, the most
overdue/missing feature of TrueCrypt nowadays, maybe I find some time in
the future... The second thing that I would like to change is the build
process that requires an outdated tool-chain and a quite complicated
setup. But for this, I definitely have no time ;-)

Best Regards

And here my forum article (the patch is attached):

Subject: two-factor pre-boot-authentication with USB stick and password


maybe someone in the TrueCrypt community is interested in the
following extension/patch of the TrueCrypt software (version 7.1a):

The extension of the pre-boot authentication is to provide a 2-factor
authentication (need ownership and knowledge) to boot the encrypted

Here are the details:
My intentions to this extension originally were:
- provide the option of a two factor authentication to be able to boot
the encrypted system (require the ownership of a hardware token in
addition to the password)
- use a hardware token as second factor that is commonly available and
easy to handle
- provide complete backward compatibility to the existing functions
- keep the extensions/changes as small and simple as possible
- provide the option to boot only using the token (with empty password)
- provide the ability to boot multiple independent instances of
encrypted Windows partitions on one hard disk (using different
encryption keys)

As "ownership" factor I chose an ordinary USB memory stick. In
practice, an USB stick can be used as bootable medium for every PC nowadays.
My first idea was to simply use the TrueCrypt emergency disk image, put
it to
an USB stick and remove the TrueCrypt boot loader from the hard disk.
So, for a real 2-factor authentication, the TrueCrypt volume header need
to be removed from the hard disk as well, otherwise someone could easily
transform this setup back to an one-factor authentication by restoring
an arbitrary TrueCrypt loader on the hard disk.

Unfortunately, this idea was too simple to work:
Firstly, although the emergency disk contains the volume header, it does
not use it for booting the encrypted system. Instead, it simply acts as
a TrueCrypt boot loader and reads the volume header from the hard disk.
In case of missing volume header on disk, it does no further try with
the volume header on the emergency disk, it only dumps "wrong password".
Secondly, in case of a patched emergency disk boot loader and a removed
volume header on hard disk, the Windows driver also reads the volume
header from hard disk on its startup.
Thirdly, I could not define an empty password for the emergency disk. I
know, an empty password is forbidden in case of password-only
authentication for security reasons. In case of a 2-factor
authentication with USB stick, I would like to offer it to lazy users
(like me). Of course, in that case the two-factor authentication will be
reduced to a one-factor-authentication (ownership evidence only), but at
least it should be possible.

As solution I had to patch the emergency loader, the Windows driver and
the TrueCrypt application. As mentioned above, I tried to minimize the
changes. From the user point of view, the results are:
Now the emergency disk tries to use its own copy of the volume header if
the volume header from disk does not work. Also, the user can create an
additional boot image that has empty password and does not output any
text at boot time. This option is called "boot disk" and creates a
modified emergency disk as ISO image. Also, the TrueCrypt application
provides an option to remove the system volume header of an encrypted

The user has to setup its bootable USB stick independently: The (extended)
TrueCrypt software does not support the creation of that. I use grub4dos
for it: It works fine and is easy to setup. Most important for the boot
manager in that area is to be able to boot from a given ISO image. In
fact the boot manager uses the ISO image of the created emergency disk
or the boot disk without password.

When all that process was setup, there obviously exist some
restrictions: The user cannot simply change the password, because the
volume header is not stored on hard disk any more. Also, the
deinstallation of the product or the decryption of the disk requires
more steps: To manage this, the user first needs to restore the volume
header (and probably the TrueCrypt boot loader) on hard disk. For this
step, the emergency disk must be used. After the step, the
deinstallation or decryption can be processed as usual.
Please note that I disabled these menu items for system volume
management in the TrueCrypt application which are not possible in the
corresponding system status.
Because the options are (maybe) not straight forward and even dangerous
for the inexperienced user, I can imagine to provide a command line
switch for the TrueCrypt application in order to provide all these
extensions, but I did not include that in my changes.

To give a short "howto", I wrote the steps to setup and remove the
system on a Windows installation as I used it for my tests:

1. setup:
- setup TrueCrypt software as usual
- System->Encrypt System Partition
-> create rescue disk
-> reboot
- encrypt system drive
- reboot (only for test whether the loader is working fine)
- (new!) start TrueCrypt -> System Volume (right mouse button)
-> create boot disk without password
-> store ISO image
- setup the USB stick in order to boot from the stored ISO image (or
from the stored emergency image)
- boot from the USB stick (only for test whether the USB stick is working)
- reboot again from hard disk (from the installed TrueCrypt loader)
- start TrueCrypt -> System Volume (right mouse button)
-> erase system volume header
- from now on the system only boots from the emergency image or the boot
- optionally, the TrueCrypt boot loader an hard disk can be removed/replaced

2. deinstallation:
- boot from emergency disk
-> F8 (repair options)
-> 3 (restore key data)
- if the TrueCrypt loader on hard disk was removed: boot from emergency disk
-> F8 (repair options)
-> 2 (restore TrueCrypt boot loader)
- reboot from hard disk (and password)
- start TrueCrypt -> System Volume
-> permanently decrypt
- normal decryption or deinstallation as usual...

I successfully tested it with a setup of two Windows XP installation in
parallel using VirtualBox on my PC.
Also I tested it on my laptop using three systems on the disk: Windows
XP (primary partition), Windows 7 (second primary partition), Linux
(installed on extended partition). I encrypted both Windows systems,
replaced the boot loader on MBR with GRUB that only shows the Linux
system, and made an USB stick containing grub4dos that is able to boot
both Windows systems and the Linux as well.
Of course I cannot guarantee that I didn't forgot something. My tests
were limited to the main functions. Because I don't know the whole
TrueCrypt code, maybe there are some more side effects...

I created a (source code) patch file based on TrueCrypt
version 7.1a. The resulting version I called 7.1b. I could not attach
the patch file here in this forum, but I would like to do it... May be I
send it later to this forum as a plain patch file...


-------------- next part --------------
A non-text attachment was scrubbed...
Name: truecrypt71a-nf-20120603.patch
Type: text/x-patch
Size: 42310 bytes
Desc: not available
URL: <http://lists.ciphershed.org/pipermail/devs/attachments/20140728/d0d7dddb/attachment-0001.bin>

More information about the devs mailing list