Whole Disk Encryption Explained

There are a lot of security professionals and lay people that seem to believe that encryption is encryption and that is simply not the case. Worse yet, vendors play into this misconception and obfuscate the issue with lots of words and phrases discussing seemingly complicated encryption key management procedures and the like that are actually meaningless when it comes to protecting data on running systems. As a result, it is time to clarify all of this misunderstanding.

First things first, we need to discuss how whole disk encryption works. As its name implies, whole disk encryption encrypts an entire disk drive. When a file on the whole disk encrypted drive is accessed, the encryption solution decrypts the file necessary using the decryption key provided at system startup and the rest of the drive remains encrypted. That way if a system failure occurs or the system is shutdown deliberately, the drive is always protected.

That is the key concept of whole disk encryption. The drive is technically only encrypted when the system is shutdown. If the system is running, the encryption is technically not in place because the operating system has the decryption key to access the disk at will. This is why whole disk encryption is great for devices like notebooks and the like that are shutdown at some point.

This is also why whole disk encryption is meaningless when applied to a server. When is a server shut down? Never. When using whole disk encryption on a running server, the only control that protects data is access controls, not encryption.

So using this definition, let us examine requirement 3.4.1 in the PCI DSS. That requirement states:

“If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts.”

The first statement that throws people is “logical access must be managed separately and independently of native operating system authentication and access control mechanisms”. In short, whole disk encryption cannot rely only on the operating system’s authentication process.

The best example of this is Microsoft BitLocker. BitLocker has a number of modes under which it can operate. It can integrate with Active Directory (AD), it can rely on a trusted platform module (TPM) chip in the computer or it can operate stand-alone.

In stand-alone mode, BitLocker requires the user to provide the BitLocker key by either manually keying it in or providing it on a USB device that stores the BitLocker key in order to boot the system. If that key is not provided, the system will not even offer the user to logon. This form of BitLocker meets the requirements set forth in requirement 3.4.1.

But then the requirement goes on and say, “Decryption keys must not be associated with user accounts”.

In stand-alone mode, the BitLocker key is not associated with the user’s credentials so it also meets this part of 3.4.1.

However, in the AD or TPM modes, BitLocker operates behind the scenes and the end user never knows that their disk is encrypted and the user still logs onto the system as always using their Windows credentials. These modes do not meet the independence requirement in 3.4.1 because all that is protecting the data is the user’s Windows credentials. And in the case of AD mode, BitLocker also does not meet the user credential disassociation requirement because the BitLocker decryption key is tied to the user’s Windows credentials.

But if people would fully read the Guidance column for requirement 3.4.1 they would read the following at the end of the guidance for 3.4.1 where the Council states:

“Full disk encryption helps to protect data in the event of physical loss of a disk and therefore may be appropriate for portable devices that store cardholder data.”


Whole disk encryption helps protect data in the event of physical loss of a disk. Period.

So with a server that never shuts down, if a drive in a SAN or NAS fails, the failed disk with whole disk encryption will be encrypted when it is pulled from the array. But if things are running just fine, whole disk encryption does nothing to protect the data.

So do not be baffled by the statements from those vendors trying to convince you that whole disk encryption on your server is going to protect your data while the server is running. That is not true.

Now you know.


28 Responses to “Whole Disk Encryption Explained”

  1. June 13, 2017 at 5:55 AM

    “And in the case of AD mode, BitLocker also does not meet the user credential disassociation requirement because the BitLocker decryption key is tied to the user’s Windows credentials.”

    Not strictly true. With the right GPOs in place, the bitlocker key is written back to AD for safe keeping. This key is written to the computer object. Not the user object.

    • June 13, 2017 at 7:13 AM

      Regardless of method, the AD integration method is still not approved because if the attacker has the device, the only thing that is protecting the encryption are the user’s credentials because there is no prompt for a passphrase for BitLocker when it is integrated with AD.

  2. 3 John
    March 16, 2017 at 6:24 AM

    In a scenario where CHD is not stored, it is simply processed/transmitted via web transaction and POS devices, is 3.4.1 applicable?

    • March 17, 2017 at 10:54 AM

      As long as you have confirmed what you are saying, then 3.4.1 is not applicable.

      • 5 John
        March 18, 2017 at 8:08 AM

        Thank you.

  3. March 15, 2017 at 11:12 AM

    Great article. Thank you very much for that interesting point of view. Does the similar train of thoughts apply for TDE encryption mechanisms for databases?

    • March 15, 2017 at 1:27 PM

      TDE (transparent data encryption) is done at the file level, not the whole disk level. TDE works great when only the application is the “user” that can decrypt. Not so good when individual users can decrypt. That is because if a user can decrypt, they have access to all data that they have views for which likely can include sensitive data.

      • March 15, 2017 at 2:20 PM

        But TDE implementation could be compliant with 3.4.1 if and only if defined user is only for the application itself? what about DBAs?

      • March 17, 2017 at 10:59 AM

        DBAs are where TDE usually is not enforced because they are DBAs and need to see the raw data to address any problems. Same could also be said of developers that may also have the same access as DBAs.

      • March 17, 2017 at 11:10 AM

        Sure, for DBA’s makes sense that TDE is not enforced, nevertheless, every CHD accessed by DBAs should be logged and audit trails must be in place. For developers, according to requirement 6, they can not have access to production data. Thanks again PCIGuru.

      • March 17, 2017 at 11:12 AM

        But developers do occasionally end up “looking” at production and should be handled the same as DBAs. Just saying. 😉

      • March 17, 2017 at 11:14 AM

        😂 Well… in theory they do not! but coming from a developers perspective myself, we “ocassionally” take a peek at production data. Cheers!

      • March 20, 2017 at 5:39 AM

        A “peek”? I know of developers that take much more than a “peek”. LOL!

  4. 14 Paul
    September 1, 2016 at 10:23 AM

    Interesting reading – i am looking for file level encryption – similair to EFS in a windows SAN/NAS environment – my client wants all their SAN/NAS data encrypted, we have offered D@RE (Disk At Rest) from the EMC SAN level , but this looks just like Bitlocker – ie. only encrypted when disk is removed.
    They currently use EFS – but i have told them that this is not really secure as there are 3rd party companies selling products that can decrypt the files without the keys

    So the client still wants the file level encryption and i have no idea what to offer in an enterprise environment – AES Crypt / VeraCrypt ???

    • September 6, 2016 at 6:20 AM

      EFS is not secure? I use Elcomsoft’s products and Elcomsoft would have to run a brute force attack against a properly generated EFS key. So it would take quite a while (probably more than a lifetime) to break a EFS key if it is properly generated.

      And that is the real key to encryption (no pun intended), key management. Keys must be strong (long – 32 characters or more, and complex), properly secured (encrypted) and stored away (key server) from the objects they secure. Proper key management will ensure that tools such as Elcomsoft do not have a chance at breaking EFS.

      If you are still concerned about EFS, look at Symantec’s file encryption solutions for another commercial solution.

      • 16 Paul
        September 6, 2016 at 6:44 AM

        So why would Elcomsoft provide a product thats mentions —

        ” Advanced EFS Data Recovery decrypts the protected files, and works in all versions of Windows 2000, XP, 2003, Vista, Windows 7, Windows 8, Windows 8.1, Windows Server 2008, Windows Server 2012. The recovery is still possible even when the system damaged, is not bootable, or when some encryption keys have been tampered with.

        Advanced EFS Data Recovery recovers EFS-encrypted data that becomes inaccessible because of system administration errors such as removing users and user profiles, misconfiguring data recovery authorities, transferring users between domains, or moving hard disks to a different PC.

        Advanced EFS Data Recovery locates the encrypted files as well as the available encryption keys, and decrypts the protected files. The direct access to the file system allows Advanced EFS Data Recovery to recover encrypted files in the most difficult cases even if the disk with data is only available without a valid user account to login into system, or when some encryption keys have been tampered with.”

        EFS is not secure?

        I was on a MS course and talking about encryption access etc – i mentioned accessing EFS files and the whole class nearly fell over laughing .. the lecturer mentioned that it was not secure/certified – Govt dosnt approve it etc.. he mentioned using AD RMS instead

      • September 6, 2016 at 9:16 AM

        What has not been approved is the use of EFS as a whole disk encryption solution. However as a file/folder solution, it has been my understanding that EFS is sufficient as long as you use AES as your algorithm and also proper key management processes.

  5. 18 LW
    June 16, 2015 at 2:30 AM

    Thanks for the article, just one question – at first we are saying that 3.4.1 is not met when using AD to access the encrypted drive. The guidance makes it clear this requirement is meant to help protect data in the event of physical loss. Does that mean using AD is ok while the server is running, or does there still need to be a separate access mechanism for the encrypted drive while the server is running?

    Any feedback would be appreciated.

    • June 16, 2015 at 5:10 AM

      Whole disk encryption is only protecting data when a device is shutdown. In the case of a server, whole disk encryption only provides protection when a disk is removed, never while the server and disk are running. Therefore, if you want to protect stored data such as a PAN, you need to use a different encryption method such as file level, folder level or column level encryption in addition to access controls. Those access controls could be provided by Active Directory (AD) or by the application.

  6. 20 M
    May 28, 2015 at 5:21 PM

    So, does anyone have an example of a product that would meet this requirement? Most of the products that I have looked at integrate with the operating system. Either local accounts or through AD.
    I was able to use non-OS/AD accounts on an older version of symantec pgp. The newer versions use the local user database.

    • May 29, 2015 at 5:39 AM

      Symantec and ESET are the only vendors I am aware that have Enterprise whole disk encryption solutions similar to AD/Bitlocker but independent of the operating and authentication systems.

  7. May 18, 2015 at 2:26 PM

    So does this mean that if I pull the disk out on a running computer and hook it up to another comuter via a usb doc will it be unencripted

    • May 19, 2015 at 12:53 PM

      If you have implemented whole disk encryption properly, no you will not be able to read the disk unless you have the encryption key.

  8. May 17, 2015 at 11:58 AM

    Reblogged this on oogenhand.

  9. 25 Louis
    May 15, 2015 at 9:37 AM

    Can we then conclude that requirement 3.4.1 sole objective is disk theft or loss ?

    Meaning, that is the risk to cover, either in applying directly the control or by demonstrating an adequacy in a risk analysis

    • May 16, 2015 at 5:31 AM

      I think that it is safe to say that 3.4.1 is all about the physical loss of HDD/SDD.

  10. 27 Chris
    May 15, 2015 at 5:46 AM

    Nicely explained

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.


May 2015
« Apr   Jun »

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,941 other followers


%d bloggers like this: