Blog Books Book Subscription

×
Join the Community!
Get expert insights straight to your inbox. Subscribe
below to receive computing updates!

SECURITY Subscribe now

How to Encrypt a Hard Drive

by Rheinwerk Computing

How can you defend yourself against physical attacks on your hard drives?

To start, know that UEFI Secure Boot is always enabled on modern Windows computers.
You should also block the ability to boot from an external drive and be sure to set a master
password for EFI/BIOS. However, these measures do not constitute absolute protection. In
particular, you can’t prevent a hacker from simply removing the hard drive or SSD and then
accessing it.

BitLocker
The only effective protection against a hacker being able to read a device’s hard drive or
SSD is to encrypt the disk entirely. Windows has integrated the BitLocker technology into the
pro and enterprise versions of Windows for this purpose.

BitLocker normally requires that the computer contains a Trusted Platform Module (TPM).
This is a chip that provides basic encryption functions according to a standard, uniquely
identifies the device with a key, and provides memory for the secure storage of additional
keys.

TPM can be implemented as a separate chip, but also as part of the CPU. Intel uses the—
from a security point of view—highly controversial Intel Management Engine (ME) for some
models and calls its TPM implementation Platform Trust Technology (PTT).

BitLocker stores the encryption key in the TPM chip. As long as Windows is booted directly
from the device, accessing the BitLocker file system therefore succeeds without the
annoying specification of a key. If, on the other hand, a hacker uses a different boot medium
or removes the hard drive/SSD from the computer, access to the encrypted file system is
only possible with the corresponding BitLocker password.

On older computers, you can use BitLocker without TPM. To do this, you must first modify a
group policy. In the Local Group Policy Editor (gpedit for short), you need to search for the
BitLocker options in the policies for the local computer.
5

Now double-click Require additional authentication at startup to change the settings for
the policy so that BitLocker also accepts a USB flash drive with a key file or the entry of a
password instead of TPM for security.

You can enable and disable BitLocker in the module of the same name in the Control Panel.
In the dialogs that follow, you can then set a password, print or save the recovery key,
choose between different encryption modes, and so on. The actual encryption takes place
after the next Windows restart (see figure below). If you use BitLocker without TPM, a USB
flash drive with the key file (*.BEK file) must be plugged into the computer. This USB flash
drive will also allow booting without BitLocker password entry in the future.

While the file system is being encrypted, you can work normally. If you want to know how far
the encryption has progressed, you should run the manage-bde command in cmd.exe or a
PowerShell window with administrator privileges:

> manage-bde -status

...

Encrypted (percent): 32.7%

Encryption method: XTS-AES 128

BitLocker to Go: External drives can also be encrypted via BitLocker to Go. This is
especially important if backups are stored there; otherwise, an unencrypted backup will
undermine BitLocker protection on the notebook.
5
Speed: Encrypting and decrypting files takes time. Fortunately, there is no significant speed
disadvantage with modern notebooks because hardware encoders or decoders help the
CPU with its work. The CPU functions are so efficient that the operation is only imperceptibly
slower due to the encryption. Modern data media themselves contain encryption functions
that could relieve Windows or the CPU. In the past, however, their security has been
repeatedly found to be inadequate. In current Windows versions, BitLocker therefore avoids
the encryption functions provided by the disk and performs the encryption itself (see http://s-
prs.co/v569640).

Access to BitLocker File Systems on Linux (dislocker)

If TPM is involved and you either know the password or have a key file, you can also access
BitLocker file systems on Linux. You will need the dislocker package, which can also be
installed in the live system:

apt install dislocker

dislocker-find determines the partitions on which BitLocker is used. With dislockermetadata,

you can also find out which encryption method BitLocker uses:

dislocker-find

/dev/sda2

dislocker-metadata -V /dev/sdb2 | grep Type

... Encryption Type: AES-XTS-128 (0x8004)

To access the contents of the partition, you need to run dislocker-fuse. The command will
ask you for the BitLocker password, without which access will not succeed:

mkdir /mnt/bitlocker

dislocker-fuse -V /dev/sdb2 -u /mnt/bitlocker/

Enter the user password: ************

If you have a *.BEK file with the BitLocker key, you can pass it with the -f option. dislocker-
fuse will still ask for the password, but it’s now sufficient to simply press (Enter):

dislocker-fuse -V /dev/sdb2 -u /mnt/bitlocker/ \

-f F622AE50-8C93-4847-8441-FAA184AFF9AD.BEK

Enter the user password: ************

However, in the /mnt/bitlocker directory mounted in this way, you will find only one file:
dislocker-file. You can now use this file as an NTFS file system in a second step with mount:

ls -lh /mnt/bitlocker/

-rw-rw-rw- 1 root root 244G ... dislocker-file

mkdir /mnt/windows

mount -o ro /mnt/bitlocker/dislocker-file /mnt/windows/

ls /mnt/windows/

BOOTNXT hiberfil.sys ProgramData Programs swapfile.sys ...

Not Compatible with TPM: dislocker fails if the BitLocker key is located in TPM memory—
which is true on most modern computers. You may have secured BitLocker with a password
(PIN) in this case as well. However, this is only a code for accessing the key, not the key
itself. Entering this code doesn’t help dislocker because the program doesn’t have access to
the “correct” key in the TPM memory.

You can find more information on this at https://github.com/Aorimn/dislocker or http://s-

prs.co/v569641.

BitLocker Security
BitLocker is considered secure according to current knowledge; that is, until mid-2022, there
was no known way to break through the protection if the computer is turned off and the
password isn’t known.

However, this only applies if the encryption is performed by Windows. If BitLocker relies on
the encryption functions of the hard drive or SSD (which was quite common in the past), the
security of the data depends on whether these encryption functions of the data carrier are
implemented without errors. Unfortunately, a look back to the past shows that not much
confidence is warranted in this regard. If necessary, you can use manage-bde -status to
check which encryption method is present on your systems. If you see Encryption Method:
Hardware Encryption, you should switch the encryption to Software Encryption.
Unfortunately, this process is very time-consuming, because first all files have to be
decrypted and then re-encrypted (see https://lifehacker.com/1830289471).

Naturally, encryption protection is highly dependent on the quality of the password. A

password that is too short or too simple can be discovered by systematic trying. Another
security risk is the storage of the key: during setup, the configuration program recommends
printing a recovery key or saving it to a USB disk.

Microsoft claims that BitLocker doesn’t contain any backdoors. Because the source code of
the software isn’t available, this statement can’t be proven. Police and intelligence agencies
have repeatedly called for such a backdoor.

The Wikipedia page on BitLocker outlines the concept of a cold boot attack. It’s based on the
fact that the BitLocker key is in memory while Windows is running: if a hacker steals the
device while it’s running and reboots it within minutes with an own boot medium, it may be
possible to read the key from memory.

Things get even easier if the attacker has access to the running, unlocked computer.
Because the BitLocker password is located in the memory, the attacker only has to succeed
in reading the entire RAM. The Passware company (https://www.passware.com) offers a
corresponding attack kit for sale. It can read the working memory via the Fire- Wire interface,
if the computer provides such an interface.

BitLocker Alternatives
In the past, the TrueCrypt program, which is available in source code, was considered an
alternative to BitLocker. However, the development of the program was discontinued in
2014. At the same time, warnings were issued about possible vulnerabilities contained in
TrueCrypt. Various forks or variants of TrueCrypt, such as VeraCrypt or GhostCrypt, never
achieved the same popularity as TrueCrypt—and were never checked to the same extent
with regard to security issues.

If you don’t want to encrypt the entire file system, but only individual files or directories, you
can use the Encrypting File System (EFS). This relatively old Windows feature (it was first
implemented in Windows 2000) is included only in selected versions of Windows, such as
the pro, enterprise, and education versions.

To use EFS features, select the Properties context menu item of a file or directory, click the
Advanced button, and then enable the Encrypt contents option (see figure below).
Surprisingly, Windows doesn’t ask for an encryption password. Rather, Windows generates
a key when the first EFS file is set up and secures access to that key with the current
account data. Access to the files is thus linked to a successful Windows login. However,
Windows recommends that you also back up the access key to an external disk and displays
a corresponding dialog after encrypting.

If a hacker tries to view the files on Linux or from another Windows account, they’ll see the
files, including the file names, but it isn’t possible to access them.

macOS: FileVault
macOS provides the FileVault encryption function, which is comparable to BitLocker.
Encryption can be enabled either in the system settings (in the Security area) or via the
sudo fdesetup enable command.

Current Macs use the T2 chip (Intel models) or functions of the M1/M2 CPU for encryption.
On older Intel models without a T2 add-on chip, encryption is associated with the login
password. So there is no separate password for encryption.

When setting up FileVault, macOS enables you to store the key in iCloud or in a local file.
The key file provides a way to access data without the login password in an emergency
case.

In terms of security, FileVault is comparable to BitLocker. The attacks outlined for Bit- Locker,
such as reading the RAM, are basically also conceivable on macOS. However, the
prerequisites for this are only given if the attacker already has access to the computer
anyway.

T2 Vulnerability: Basically, Apple’s encryption method is considered mature and secure.

However, the T2 chip has been found to have a serious security issue that can’t be fixed by
updates (Checkm8). An attacker can gain unrestricted access to the computer via a
manipulated USB-C cable. For more information, see https://ironpeak.be/blog/crouching-t2-
hidden-danger.

Linux: Linux Unified Key Setup

There are several methods to encrypt a file system on Linux. The most popular is Linux
Unified Key Setup (LUKS). It’s based on the dm_crypt kernel module, which extends the
device mapper, which is responsible for accessing partitions or block devices in general,
with cryptography functions. The module thus forms a logical layer between the encrypted
raw data on the hard drive/SSD and in the file system as seen by the user. dm_ crypt is
often combined with LVM, but this isn’t mandatory.

Subsequent setup of LUKS is only possible with a very time-consuming and high
administration effort. That’s why it is recommended to set up LUKS right at the time of its
installation. All common Linux distributions provide corresponding options: on Ubuntu, you
need to select Encrypt the new Ubuntu installation for security in the installer; on RHEL
and CentOS, you must select Encrypt my data in the partitioning dialog. With both
distributions, encryption already occurs at the LVM level. This way, all logical volumes are
encrypted (i.e., all virtual partitions that will later contain file systems or swap space).

Unlike Windows, where the BitLocker key is stored in the TPM chip if possible, or macOS,
where key access is secured with the login password, Linux always requires the LUKS
password to be entered at the beginning of the boot process. An unattended restart isn’t
possible without further ado. LUKS is thus well suited for notebooks, but not for servers
running in a remote data center or in remote basements.

Security Concerns Regarding LUKS

Linux is more secure than Windows, it’s often said. Depending on the application, that may
be true, but definitely not as far as SSD/hard drive encryption on desktop systems is
concerned. The problem is not LUKS itself; the encryption as such is considered secure.
The problem is rather the environment.

On macOS and Windows 11, it’s common to store the key via TPM and secure it via the
normal login password. On Linux, on the other hand, two separate passwords are required,
which is extremely impractical, especially if a computer is used by several people.
Furthermore, it’s much more difficult to intervene in the boot process on macOS and
Windows than it is on Linux.

For this reason, two attack paths are conceivable in Linux that would not work in the same
way with a current macOS or Windows installation:

In the first case, the attacker manipulates the boot process in such a way that the user
thinks he or she is entering the decryption password. However, this password is
actually tapped and can subsequently be used by the attacker to decrypt the data.
In the second case, the attacker temporarily removes the SSD, copies the encrypted
data, and reinstalls the device. Afterward, the attacker can try to guess the password at
his leisure in a brute force attack. (Only a long password can prevent this.) On macOS
or Windows 11, this attack path is impossible because the key is located in the
notebook itself (in the TPM chip or in the CPU). The SSD can’t be read from the
notebook under any circumstances.

Both hacking variants are admittedly complex and require physical access to the notebook.
Nevertheless, the following applies: recent versions of Android, iOS, macOS, and Windows
do a better job. Linux developer Lennart Poettering wants Linux to be just as secure. He has
described in detail the underlying problems and a conceivable approach to solving them
(which, however, will probably take years to implement. See http://sprs.co/v569642 and
http://s-prs.co/v569643.

File System Encryption on the Server

After reading this post, it should be clear to you that the file systems of company notebooks
should always be encrypted—regardless of whether the devices use Windows, macOS, or
Linux as their operating system.

But what’s the recommendation for servers? The answer depends on several factors. The
first question is where the servers are located. If they’re in locked rooms to which only a few
people have access, there’s often no need for encryption at all. If, on the other hand, the
server of a small company is located in a room to which everyone has access, encryption is
very much appropriate.

Another factor is the operating system: Windows servers with TPM can be restarted without
much additional effort even if encryption is enabled. Linux servers, on the other hand,
require the manual entry of the LUKS password each time they are restarted. For this
purpose, an administrator must have physical access to the computer. For servers that are
usually administrated through the network (e.g., with SSH), this is extremely inconvenient.
For root servers running in an external data center, the approach is simply impossible.

NAS devices represent a special case: with many devices, a hard drive can be removed with
a flick of the wrist. So, for example, if an attacker comes to a company as a visitor and sees
an unattended NAS device, they can steal a hard drive in no time.

With common NAS operating systems, you usually can’t encrypt the system as a whole, but
you can encrypt individual directories. However, this makes handling more cumbersome.
After a reboot—for example, after an update—the encrypted directories must be explicitly
“opened” via the web interface of the NAS device by specifying the password. Until that
happens, the directories aren’t available on the corporate network. As is so often the case,
the question arises as to where the right compromise lies between high security and
sufficient convenience.

Editor’s note: This post has been adapted from a section of the book Hacking and Security:
The Comprehensive Guide to Penetration Testing and Cybersecurity by Michael Kofler,
Klaus Gebeshuber, Peter Kloep, Frank Neugebauer, André Zingsheim, Thomas Hackner,
Markus Widl, Roland Aigner, Stefan Kania, Tobias Scheible, and Matthias Wübbeling.

Recommendation

Hacking and Security

Uncover security vulnerabilities and harden your
system against attacks! With this guide you’ll learn
to set up a virtual learning environment where you
can test out hacking tools, from Kali Linux to hydra
and Wireshark. Then expand your understanding of
offline hacking, external safety checks, penetration
testing in networks, and other essential security
techniques, with step-by-step instructions. With
information on mobile, cloud, and IoT security you
can fortify your system against any threat!

Learn More

by Rheinwerk Computing
Rheinwerk Computing is an imprint of Rheinwerk Publishing and
publishes books by leading experts in the fields of programming,
administration, security, analytics, and more.

Security

Comments

FIRST NAME*

LAST NAME

EMAIL*

WEBSITE

COMMENT*

This reCAPTCHA is for testing purposes only. Please report to the

site protected
admin if you areby reCAPTCHA
seeing this.

Privacy - Terms

Submit Comment

Latest Blog Posts

SECURITY SECURITY

Ways to Encrypt a Hard Drive Securing Linux Using 2FA with Google
Authenticator
Read More
Read More

Subscribe to our blog!

Get notified about future blog updates.

Your Email Address* Submit

The official Rheinwerk Computing Blog Blog Topics

Rheinwerk Computing is an imprint of Rheinwerk Publishing and publishes resources All Topics Web Development HTML & CSS
that will help you accelerate your computing journey. The Rheinwerk Computing Blog
Programming DevOps Security
is designed to provide helpful, actionable information on a variety of topics, including
Languages
programming, administration, security, and analytics! Python What Is?
JavaScript
Software
Java Development

Blog curated by About

Home Contact Privacy Policy

Visit Rheinwerk Computing Store
About Us Legal Notes Terms of Use
© 2024 Rheinwerk Publishing, Inc. | Change Privacy Options