Disk encryption: Difference between revisions

Revision as of 13:46, 5 November 2020

Latest revision as of 13:07, 24 July 2025

(28 intermediate revisions by 22 users not shown)

Line 1:

{{Short description|Data security technology}}

'''Disk encryption''' is a technology which protects information by converting it into unreadable code that cannot be deciphered easily by unauthorized people or processes. Disk encryption uses [[disk encryption software]] or [[disk encryption hardware|hardware]] to [[encryption|encrypt]] every [[bit]] of [[data]] that goes on a [[disk storage|disk]] or disk [[volume (computing)|volume]]. It is used to prevent unauthorized access to data storage.<ref>{{Cite web|title=What is Full-Disk Encryption? - Definition from Techopedia|url=http://www.techopedia.com/definition/13623/full-disk-encryption-fde|access-date=2021-04-25|website=Techopedia.com|language=en}}</ref>

The expression ''full disk encryption (FDE)'' (or ''whole disk encryption'') signifies that everything on the disk is encrypted, but the [[master boot record]] (MBR), or similar area of a bootable disk, with code that starts the [[operating system]] loading sequence, is not encrypted. Some [[hardware-based full disk encryption]] systems can truly encrypt an entire [[boot disk]], including the MBR.

== Transparent encryption ==

'''Transparent encryption''', also known as '''real-time encryption''' and '''on-the-fly encryption''' ('''OTFE'''), is a method used by some [[disk encryption software]]. "Transparent" refers to the fact that data is automatically [[Encryption|encrypted]] or decrypted as it is loaded or saved.

With transparent encryption, the files are accessible immediately after the [[key (cryptography)|key]] is provided, and the entire [[volume (computing)|volume]] is typically [[mount (computing)|mounted]] as if it were a physical drive, making the files just as accessible as any unencrypted ones. No data stored on an encrypted volume can be read (decrypted) without using the correct [[password]]/[[keyfile]](s) or correct [[key (cryptography)|encryption keys]]. The entire [[file system]] within the volume is encrypted (including file names, folder names, file contents, and other [[Metadata|meta-data]]).<ref>{{cite web|url=https://www.grc.com/misc/truecrypt/TrueCrypt%20User%20Guide.pdf|title=Truecrypt User Guide|author=|date=|website=grc.com}}</ref>

To be [[Transparency (human-computer interaction)|transparent]] to the end-user, transparent encryption usually requires the use of [[device driver]]s to enable the [[encryption]] process. Although [[System administrator|administrator]] access rights are normally required to install such drivers, encrypted volumes can typically be used by normal users without these rights.<ref>{{cite web|url=https://github.com/t-d-k/librecrypt/blob/master/docs/installation_and_upgrading__PC.md#automatic-installation|title=t-d-k/LibreCrypt|author=|date=|website=GitHub}}</ref>

In general, every method in which data is seamlessly encrypted on write and decrypted on read, in such a way that the user and/or [[application software]] remains unaware of the process, can be called transparent encryption.

== Disk encryption vs. filesystem-level encryption ==

Disk encryption does not replace file encryption in all situations. Disk encryption is sometimes used in conjunction with [[filesystem-level encryption]] with the intention of providing a more secure implementation. Since disk encryption generally uses the same [[key (cryptography)|key]] for encrypting the whole drive, all of the data iscan be decryptabledecrypted when the system runs. However, some disk encryption solutions use multiple keys for encrypting different volumes. If an attacker gains access to the computer at run-time, the attacker has access to all files. Conventional file and folder encryption instead allows different keys for different portions of the disk. Thus an attacker cannot extract information from still-encrypted files and folders.

Unlike disk encryption, filesystem-level encryption does not typically encrypt filesystem [[metadata]], such as the directory structure, file names, modification timestamps[[timestamp]]s or sizes.

==Disk encryption and Trusted Platform Module==

[[Trusted Platform Module]] (TPM) is a [[secure cryptoprocessor]] embedded in the [[motherboard]] that can be used to [[authentication|authenticate]] a hardware device. Since each TPM chip is unique to a particular device, it is capable of performing platform [[authentication]]. It can be used to verify that the system seeking the access is the expected system.<ref>{{Citation|title=Information technology. Trusted platform module|url=http://dx.doi.org/10.3403/30177265u|publisher=BSI British Standards|doi=10.3403/30177265u|access-date=2020-12-04|url-access=subscription}}</ref>

A limited number of disk encryption solutions have support for TPM. These implementations can wrap the decryption key using the TPM, thus tying the [[hard disk drive]] (HDD) to a particular device. If the HDD is removed from that particular device and placed in another, the decryption process will fail. Recovery is possible with the decryption [[password]] or [[security token|token]]. The TPM can impose a limit on decryption attempts per unit time, making brute-forcing harder. The TPM itself is intended to be impossible to duplicate, so that the brute-force limit is not trivially bypassed.<ref>{{cite web |last1=Poettering |first1=Lennart |title=Authenticated Boot and Disk Encryption on Linux |url=https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html |website=0pointer.net}}</ref>

Although this has the advantage that the disk cannot be removed from the device, it might create a [[single point of failure]] in the encryption. For example, if something happens to the TPM or the [[motherboard]], a user would not be able to access the data by connecting the hard drive to another computer, unless that user has a separate recovery key.

Line 26 ⟶ 27:

== Implementations ==

{{Main|Comparison of disk encryption software|Disk encryption hardware|Disk encryption theory}}

There are multiple tools available in the market that allow for disk encryption. However, they vary greatly in features and security. They are divided into three main categories: [[disk encryption software|software]]-based, hardware-based within the storage device, and hardware-based elsewhere (such as [[CPU]] or [[host bus adaptor]]). [[Hardware-based full disk encryption]] within the storage device are called self-encrypting drives and have no impact on performance whatsoever. Furthermore, the media-encryption key never leaves the device itself and is therefore not available to any virusmalware in the operating system.

The [[Trusted Computing Group]] [[Opal Storage Specification]] provides industry accepted standardization for self-encrypting drives. External hardware is considerably faster than the software-based solutions, although CPU versions may still have a performance impact{{clarify|date=August 2019}}, and the media encryption keys are not as well protected.

There are other (non-TCGA/OPAL based) self-encrypted drives (SED) that don't have the known vulnerabilities of the TCG/OPAL based drives (see section below).<ref>{{Cite web |title=ClevX's DataLock Secures M.2 SSDs With a Smartphone |url=https://www.tomshardware.com/news/clevx-datalock-secures-m2-ssds-with-smartphone |access-date=2023-12-28 |website=Tom's Hardware |date=18 October 2022 |language=en}}</ref> They are Host/OS and BIOS independent and don't rely on the TPM module or the motherboard BIOS, and their Encryption Key never leaves the crypto-boundary of the drive.

All solutions for the boot drive require a [[pre-boot authentication]] component which is available for all types of solutions from a number of vendors. It is important in all cases that the authentication credentials are usually a major potential weakness since the [[symmetric cryptography]] is usually strong.{{clarify|date=October 2017|reason=This sentence is ambiguous and vague: is it "It is important to note..."? What does "usually strong" mean?}}

Line 42 ⟶ 45:

# No need for the user to carry a disc with recovery encryption key.

# No secret data is exchanged during the recovery process.

# No information can be [[Sniffing attack|sniffed]].

# Does not require a network connection, i.e. it works for users that are at a remote ___location.

Line 56 ⟶ 59:

==Security concerns==

Most full disk encryption schemes are vulnerable to a [[cold boot attack]], whereby encryption [[key (cryptography)|keys]] can be stolen by [[Cold boot attack|cold-booting]] a machine already running an [[operating system]], then dumping the contents of [[static random access memory|memory]] before the data disappears. The attack relies on the [[data remanence]] property of [[computer memory]], whereby data [[bit]]s can take up to several minutes to degrade after power has been removed.<ref name="ColdBoot">{{cite paperweb|url=http://citp.princeton.edu/memory/|title=Lest We Remember: Cold Boot Attacks on Encryption Keys|author=[[J. Alex Halderman]], [[Seth Schoen|Seth D. Schoen]], [[Nadia Heninger]], William Clarkson, William Paul, Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, and [[Edward Felten|Edward W. Felten]]|publisher=[[Princeton University]]|date=2008-02-21|accessdateaccess-date=2008-02-22|journal=|archive-url=https://web.archive.org/web/20110722182409/http://citp.princeton.edu/memory/|archive-date=2011-07-22|url-status=dead}}</ref> Even a [[Trusted Platform Module]] (TPM) is not effective against the attack, as the operating system needs to hold the decryption keys in memory in order to access the disk.<ref name="ColdBoot"/>

Full disk encryption is also vulnerable when a computer is stolen when suspended. As wake-up does not involve a [[BIOS]] boot sequence, it typically does not ask for the FDE password. Hibernation, in contrast goes via a BIOS boot sequence, and is safe.

All software-based encryption systems are vulnerable to various [[side channel attack]]s such as [[acoustic cryptanalysis]] and [[hardware keylogger]]s. In contrast, self-encrypting drives are not vulnerable to these attacks since the hardware encryption key never leaves the disk controller.

Also, most of full disk encryption schemes don't protect from data tampering (or silent [[data corruption]], i.e. [[Data degradation|bitrot]]).<ref>{{cite web|url=https://crypto.stackexchange.com/a/10808|title=Practical disadvantages of GCM mode encryption|author=|date=|website=Cryptography Stack Exchange}}</ref> That means they only provide privacy, but not integrity. [[Disk encryption theory#Block cipher-based modes|Block cipher-based encryption modes]] used for full disk encryption are not [[authenticated encryption]] themselves because of concerns of the storage overhead needed for authentication tags. Thus, if tampering would be done to data on the disk were tampered with, the data would be decrypted to garbled random data when read and hopefully errors may be indicated depending on which data is tampered with (for the case of OS metadata – by the file system; and for the case of file data – by the corresponding program that would process the file). One of the ways to mitigate these concerns, is to use file systems with full data integrity checks via [[checksum]]s (like [[Btrfs]] or [[ZFS]]) on top of full disk encryption. However, [[cryptsetup]] started experimentally to support [[authenticated encryption]]<ref>{{cite web|url=https://gitlab.com/cryptsetup/cryptsetup/blob/master/docs/v2.0.0-ReleaseNotes#L192|title=docs/v2.0.0-ReleaseNotes · master · cryptsetup / cryptsetup|authorwebsite=GitLab|date=|website=GitLab16 April 2022 }}</ref>

==Full disk encryption==

Line 74 ⟶ 77:

=== The boot key problem ===

One issue to address in full disk encryption is that the blocks where the [[operating system]] is stored must be decrypted before the OS can boot, meaning that the key has to be available before there is a user interface to ask for a password. Most Full Disk Encryption solutions utilize [[Pre-Boot Authentication]] by loading a small, highly secure operating system which is strictly locked down and hashed versus system variables to check for the integrity of the Pre-Boot kernel. Some implementations such as [[BitLocker Drive Encryption]] can make use of hardware such as a [[Trusted Platform Module]] to ensure the integrity of the boot environment, and thereby frustrate attacks that [[rootkit#Boot loader level|target the boot loader]] by replacing it with a modified version. This ensures that [[authentication]] can take place in a controlled environment without the possibility of a bootkit being used to subvert the pre-boot decryption.

With a [[pre-boot authentication]] environment, the key used to encrypt the data is not decrypted until an external key is input into the system.

Line 98 ⟶ 101:

*[[Disk encryption theory]]

*[[Encryption]]

*[[Encryption layer in storage stack]]

*[[Filesystem-level encryption]]

*[[Hardware-based full disk encryption]]

Line 109 ⟶ 111:

==Further reading==

*{{cite journal |last=Casey |first=Eoghan |authorlink= |author2=Stellatos, Gerasimos J. |year=2008 |title=The impact of full disk encryption on digital forensics |journal=Operating Systems Review |volume=42 |issue=3 |pages=93–98 |doi=10.1145/1368506.1368519 |url= |accessdate= |quotes2cid=5793873 }}

==External links==

* [httphttps://wwwobamawhitehouse.whitehousearchives.gov/omb/memoranda/fy2006/m06-16.pdf Presidential Mandate requiring data encryption on US government agency laptops]

* [https://web.archive.org/web/20130117220829/http://otfedb.sdean12.org/ On-The-Fly Encryption: A Comparison] – Reviews and lists the different features of disk encryption systems (archived version from January 2013)

* [{{cite web|url=http://www.markus-gattol.name/ws/dm-crypt_luks.html |archive-url=https://web.archive.org/web/20150917051251/http://www.markus-gattol.name/ws/dm-crypt_luks.html All about on|title=Block-disk/full-disklayer encryption on|archive-date=Sep one17, page]2015}} – coversCovers the use of dm-crypt/LUKS on Linux, starting with theory and ending with many practical examples about its usage (archived version from September 2015).

* [http://www.esecurityplanet.com/mobile-security/buyers-guide-to-full-disk-encryption.html Buyer's Guide to Full Disk Encryption] – Overview of full-disk encryption, how it works, and how it differs from file-level encryption, plus an overview of leading full-disk encryption software.