I am having a debate with several people regarding how much protection full disk encryption provides. dm-crypt is being used to encrypt data which is required by my company to be encrypted at rest. The Linux servers hosting the data reside in a secure data center with very little risk of unauthorized physical access, let alone someone actually stealing the server.

My argument is that in this situation, that while complying with the letter of the law, they have done little to nothing to actually reduce risk associated with unencrypted data. In effect, from a logical standpoint, they are in the exact same situation than if no encryption had been implemented at all. I am curious though if this train of though is correct, thoughts?

To tailor the question more to my specific situation, regarding physical protection, the controls around that are typically very sound. I am not saying risk is eliminated but it is considered to be low. Same with disposal of the drives, the destruction controls operate pretty effectively and risk is considered low. From a logical access standpoint the servers are not Internet facing, are behind a firewall, logical access is well controlled (but many have access), and they are not virtualized. Further, the servers operate 24x7, the only time they are rebooted is if it's needed after a change or during installation of a new one.

My concern is that in the event an insider goes rogue, or an unauthorized user exploits a logical security flaw, then the full data encryption does nothing to protect the data versus using some of the other field or file level encryption tools available. Whereas the people I am debating argue that this is not the case.

  • 4
    Thoughts that come to mind: If a server is off, the drivers can be stolen. There's nothing wrong with indepth security. If the server is switched off, what does one prevent from disconnecting the network from the server and boot it? Just thinking out loud here.
    – Jeroen
    Commented May 22, 2015 at 6:40
  • 1
    It isn't entirely pointless but adds a layer of complexity and slightly reduces performance.
    – user42178
    Commented May 22, 2015 at 12:17
  • 8
    If your company is doing anything interesting at all, then there is always the risk of people with smiles and warrants who will want hardware access to your server for a few hours. Of course, only them and the DC employees know that has happened. FDE might help protect your clients in this situation, even if neither you nor them know it.
    – dotancohen
    Commented May 22, 2015 at 13:14
  • 5
    The maintenance contract on our storage array requires that failed disks be sent back to the company after swapping out (or we pay a hefty "non-return" fee on the drives). Without disk encryption, returning disks may not be possible since you can't wipe a failed disk. We had a power supply take out an entire disk tray once -- that would have cost us around $40,000 in non-returned disk fees.
    – Johnny
    Commented May 23, 2015 at 3:57
  • 2
    @syneticon-dj currently the security is moot for self-encrypting drives. We can't even trust their "secure" erase function, why should we trust their encryption ? And complexity shouldn't be overlooked especially if you plan on entering the key remotely. I've looked at the solutions for this on Linux and it still looks not reliable for production usage.
    – user42178
    Commented May 23, 2015 at 14:52

10 Answers 10


Two generic things you apparently have missed:

  • In case of disk failure, having the data encrypted at rest solves the issue of having potentially sensitive data on a media you can't access any more. It makes disposing of faulty drives easier and cheaper (and it's one less problem)

  • Full disk encryption also makes it harder for an attacker to retrieve data from the "empty" space on the drives (which often contains trace of previously valid data)

And if you're using VMs:

  • Encrypting the partition makes you less dependent on the security of your hypervisor: if somehow the raw content of one of your drive "leaks" to another VM (which could happen if the drive space is reallocated to another VM and not zeroed out), that VM will be less likely to have access to the actual data (it would need to obtain the decryption key as well).
  • 6
    The VM comment is a good point and something I have not thought of. The servers I am debating though are not virtualized, they host only one application. Commented May 22, 2015 at 13:26
  • I have often had this debate and I appreciate these points as they make a lot of sense. However, they don't address the original question, which is whether encrypting the drives offers any inherent security in of itself while the server is operational? Every security expert I speak to says no. The only value comes when the drives are offline/disconnected. Commented May 23, 2015 at 7:02
  • 1
    @JohnVirgolino FDE is explicitly labeled as "Data at rest protection". Why should it add protection to an online, unlocked (i.e. decrypted) disk? Commented May 23, 2015 at 9:21
  • 2
    → Stephane: point 1. & 3. are risks correctly covered by a full disk encryption. For point 2. I'm not so sure. For me on many OSes, if an attacker has access to the uncrypted running disk, then the IO buffers, and the part of the disk used for virtual memory are also accessible through a basic read. If I'm wrong could you improve this point 2.?
    – dan
    Commented May 25, 2015 at 22:06
  • @danielAzuelos That's one of the reasons why I wrote "make it harder" instead of "protects against".
    – Stephane
    Commented May 26, 2015 at 6:50

If the decryption key is stored in plain on the very same media as the encrypted data, then the encryption is pointless. If you have a set of rules, which require data to be encrypted, but permit storing the key in plain on the very same media, then the rules are flawed. If you ever face such a flawed set of rules, you should point out the flaw.

If the key is not stored on the same media as the data. Then the encryption does serve a purpose. That does however raise the question about where the server gets the key from at boot. There are a few options:

  • Require a password to be entered during boot. This is not very practical for a server.
  • Fetch the decryption key from a key server. This can prevent the data from being decrypted if the server was stolen, it just requires the key server to only respond to requests from within the data center.
  • Secret share the key across multiple disks. Does nothing for the case where the server is stolen. But if you have a RAID where single disks are occasionally replaced, it guarantees that any data left on disks returned under warranty is properly encrypted. When a new disk is added to the RAID, an implementation of this technique would have to do the following:
    • Generate an encryption key for this individual disk.
    • Generate a new master key.
    • Secret share the new master key across all disks.
    • On each disk write the disk encryption key encrypted under the new master key.

The three approaches described above can be combined. If they are combined, the key server could be implemented using blinded RSA.

  • 4
    Hopefully if you are going to the trouble of FDE using dm-crypt you recognize the need for a TPM to house the decryption key. The things you mentioned are obviated by properly using a TPM, since the key never leaves it and it integrates tightly with the OS and FDE software to decrypt as-needed without exposing itself to simple reverse engineering.
    – Jeff Meden
    Commented May 22, 2015 at 15:35
  • 3
    @JeffMeden: Special care must be taken to ensure that the TPM chip does not become a single point of failure. This will indeed tie the content of the disks to the TPM chip and the motherboard, if the motherboard dies, then the disk content may not be retrievable... Commented May 22, 2015 at 15:56
  • 1
    @JeffMeden You'd be trusting the tamper resistance against an attacker who can use as much time as they like to break it. The attacker would have stolen the server including all the key material needed in order to decrypt. The attacker could even boot the machine and try to attack it through the network in a setup where no IDS can alert anybody, and nobody can cut off the attackers network connection to the target. That doesn't sound very robust to me. I'd much rather rely on the attacker not stealing every server in the data center in order to have the decryption key.
    – kasperd
    Commented May 22, 2015 at 15:58
  • 1
    @LieRyan For the third time: The key server must only respond to requests from the local network. Once the server has been stolen, it is no longer on the local network.
    – kasperd
    Commented May 27, 2015 at 12:48
  • 1
    @LieRyan Sure permission has a specific meaning in that context. But once the server has been stolen and is in a location controlled by the adversary, we are no longer in that context. And all of the physical security measures may reduce the risk of theft, but it does not eliminate it. With proper social engineering a person could walk in, pick up a server, and walk away with it.
    – kasperd
    Commented May 27, 2015 at 22:48

There are attacks on the firmware of hard disks. Googling for hard drive firmware attack will return some results about what the NSA does or can do, which probably isn't very relevant to you; but even hobbyists are able to modify the firmware of drives. This guy even installed a linux kernel on his hard disk - no, it wasn't the PC that ran linux, the hard disk controller itself did that.

If someone gains access to the firmware of your disks (for example, that somebody rents a server from your data center for a month, then returns it; the data center company wipes the drives, then assigns that server to you), they might have the drive firmware do something like "Whenever a block that's written to disk contains a special pattern, for the next 5 minutes, in every read block that starts with root:$1$, replace the first bytes with (some password hash)", you have an attack that's nearly undetectable. Your /etc/shadow file will look normal to you except during the 5 minute time window after your attacker requested a file with a name containing the trigger pattern from your web server, which wrote it to its error log.

Unlikely? Sure. Impossible? Definitely not. Is it paranoid to assume this could happen? Probably yes, depending on how interesting your data is. But, encrypting your drives will protect you from this kind of attack, and it won't cost you anything but a few cpu cycles. And, if there are any laws or regulations to follow, in case of a security breach, i certainly don't want to be in the position to have explain why i thought it wouldn't matter.


Consider what you mean by 'secure' data center.

Generally, I don't consider anything secure against a determined and well-resourced attacker. True, having 18" of reinforced concrete, double man-traps, and armed security provides a fair amount of protection, but it's rare that this protection is all just for you. In most co-location facilities, the only thing guarding you from a person with $500 and enough knowledge to rent rack space in the same facility as you is a dubiously secure wire cage with a three pin tumbler.

Occasionally, natural and man-made disasters will flood things, cut power, poison water supplies and do all sorts of unusual things that cause security guards and technicians to not show up for work or just go home to their families - what I'm saying is that data centers only provide a level of security that is probably not as much as many of their customers think.

Reconsider your stance on the low risk of your disposal contractor losing drives.

A certificate of destruction entitles you too..... the $20 back that you paid them to destroy a drive that didn't actually get destroyed?

Have you visited your drive disposal facility? Checked their hiring procedures? Seen their safeguards? Make sure you're rock-solid on this because it's one of the most obvious vulnerabilities - a change in custody.

So, that's not at all what you asked, how about the insider-threat you actually asked about.

Ok, an insider would have access through your FDE and would see the files unencrypted. In your FDE scenario, it will do nothing to stop or slow the insider from getting at the data.

What it will do is funnel your insider-threat to go through your FDE, which would allow you to log, monitor, and identify a culprit, or at least a suspect. Being able to identify your attacker is a layer of security.

But, I'm pretty sure funneling is not primarily what FDE is for. Even if you do have FDE you can still implement another file-level or other data encryption on top of FDE. You can also still use the operating system's access controls.

FDE protects against insiders that don't have access through the FDE. It guards against server technicians replacing drives taking one and making off with data. It guards against an employee of the server facility picking one up out of a shipping container at your facility waiting for transport to your destruction contractor.

FDE allows you another level to stop insider-threats as well, if you segregate your farm or use granular access - say your insiders only have access to certain servers, etc. FDE would prevent them from simply copying drives wholesale that they don't have access through the FDE for.

Simply put, FDE protects the data on the drive from physical access to the drive. You can try to control physical access as much as you'd like, but the drives will always find themselves with some vulnerability (being stolen by insiders, being copied by insiders, transiting custody where insiders touch it, unguarded due to a disaster, etc). If people touch the drive, FDE is a layer of defense against it.



Not surely. It depends on, against what you want to defend yourself. Some examples:

  • If you live in a country, where the government can confiscate your server to analyze its content and then use it against you, or your employer.
  • If you are the owner of the server, but won't give the possibility of your employee/collegues having physical access to it, that they stole/mirror its content. Then you enable them to service/boot it, but don't give them the encryption keys.
  • Same could be serve as an efficient protection if you can't/won't trust your server hosting solution.

It depends on the circumstances. These circumstances I shown as example, are at least uncommon in my environment, but they could be possible.

If you are in a regular business environment, don't do it. It taked a lot of work hours away, and has an extended service time. On my opinion, in most cases it doesn't worth its price.


From your description, I suspect your correct. That is, full disk encryption does not add any real protection for your data on a running server should someone compromise that server to extract the data. This is not what full disk encryption is designed to achieve. However, this doesn't mean there is no case for having full disk encryption on a server. As pointed out in other posts, there are good reasons to have full disk encryption on a server, such as protecting against theft, effective control for disk disposal or having to return failed disks to vendor etc. However, if you need to protect the data on the server when it is running, you will usually need file, table, etc encryption on top of disk encryption - it isn't necessarily an either/or situation.

The other thing to consider is that security is about layers of protection. Suggesting that you have good controls in place for disposal of disks and therefore you don't need full disk encryption assumes that the controls used in disposing of disks will never fail. However, these types of controls usually have a high procedural and human content - it relies heavily on the admin following the procedure correctly. In my experience, these are the types of controls which are more likely to fail. It could be that new employee who just forgets or is not aware of the procedure, it could be that experienced sys admin dealing with a high pressure failure where the boss is pressuring him to get the service back up ASAP etc. Having full disk encryption is simply another protective control which takes some of the pressure off staff and reduces the possible impact from a simple human error.

Where things go wrong with full disk encryption is when people assume it solves more problems than it actually does - this would seem to be the thrust of your argument/concern. I have seen many vendors and even admins convince management that the data is safe simply because it uses full disk encryption. As a result, little if any real risk analysis is done regarding the risks when the server is running. I recently did a large data storage project for a client which involved potentially sensitive and/or valuable data. It was quite surprising the number of vendors who didn't address the encryption questions correctly. Their stock answer was that "its ok, the system uses full disk encryption". Once I drilled down and gave examples and asked how their full disk encryption would protect against various scenarios for a running server, their general answer was "Oh, well thats a problem which the application needs to solve".

For me, the biggest issue I've run into with both full disk encryption and file/table level encryption is the frequent lack of any real consideration regarding key management. For me, most of the solutions seem weak in their support for enabling consistent and reliable key management. There have been many times I've seen a system where I've been told about all the wonderful use of encryption to protect the data only to find that the keys used are poorly protected - almost an after thought. Worse still, due to the lack of a good or understood approach, you come across data centres where the same key is used in multiple places or at multiple levels just so that the admins can manage them effectively and be able to recover when necessary.


Quote: " . . .they have done little to nothing to actually reduce risk associated with unencrypted data. . ."

Ok, yeah, I think you are right. The simple answer is "it is pointless", but "it is also NOT pointless." Which is why, and forgive me for saying this, I think you may be barking up the wrong tree. Let me explain. The full disk encryption (FDE) does serve some purpose - even if it is only for a subset of exploits that are of low probability. There are a number of possible exploits - and LOW probability does not equal NO probability.

So, is it pointless? Not entirely. But why are you arguing against it? Do you want more attention paid to the security when the servers are running, and the data is unencrypted? This enters the region where facts may do you less good, and a sense of politics may stand you in good stead.

It could be that your goal in this argument at work is to establish your expertise. Or maybe there is something you think needs doing, and nobody is paying attention. All the above are valid and reasonable, and part of the everyday workplace environment. I could be misreading your question, but it seems to me you might get a better result by arguing for the action you think needs to be done, rather than against an action that IS being done. Pick your fights.


Thank you everyone for the feedback. In summary, the title question, is FDE for a server in a secure data center pointless? The answer is not necessarily as there could be scenarios where one would want the additional protection on the physical devices. For instance protection during destruction, protection from the host country, or protection in case of disk failure among other situations.

In the text the question was somewhat changed from that stated in the title. The concern in the main question was the data being compromised not via physical access to the server but logical access to the data. Based on the responses, it appears that FDE does not provide this protection. The solution is transparent to the user where the data is decrypted at the server upon boot. At that point one is reliant on other controls such as firewalls, good access management, strong authentication, and patching.

My preference is that in addition to those controls for file or field level encryption to be used with access to the encryption keys being restricted to provide an additional layer of security.

One thing that I didn't see mentioned is that I have heard that FDE can also provide protection from certain types of malware which might programmatically copy the information. However, I have not been able to confirm this statement through research.


Here are 2 more advantages (assuming you use new encryption keys each time you re-install):

  • If you run file recovery tools that scan the full block device, e.g. PhotoRec, you do not have to checks tons of old files that are no longer of interest.

  • If you run filesystem repair tools that scan the full block device, you do not run the risk of confusing structures and meta-data of an old filesystem with the current one.



If you use Confidential Cloud Computing (https://security.stackexchange.com/a/241566/84564) you need to have FDE.

But you will not need a secure data center to guard the confidentiality: Unless the attacker works with AMD or is really skilled at bypassing the security in the CPU, your data is safe. Even if the full computer is stolen.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .