29

From the way I understand it, at-rest encryption is used to protect data when it's being stored at a datacenter so that if someone manages to get data they shouldn't have, they don't have anything useful. But regardless of what type of encryption is being used, the key (or some other method) also has to be stored somewhere - readily accessible for decryption. So, wouldn't it be simple for someone to just undo the encryption? Given they already gained access.

Am I just not getting how it works or is there some other concept I'm not taking into consideration?

9
  • 23
    It is easier to keep a small key protected than to keep an unencrypted hard drive protected. In practice, when you do full-disk encryption you will often store key material used for decryption in a very-hard-to-attack hardware security module on the motherboard (e.g., TPM). In this case, for example, if someone removed the drive they can not access the data (since it is encrypted). Even if someone has the entire computer they will have a very hard time extracting the key from the HSM without a lot of electron microscope time and patience.
    – hft
    Jan 14, 2022 at 2:17
  • 17
    @hft That's worth putting into an answer.
    – nobody
    Jan 14, 2022 at 2:23
  • 1
    The key is to devise a method so that when the hardware is stolen, the key is separated from it. Or if it is tampered with (such as rebooting from external media), the key becomes unavailable (tpm).
    – user10489
    Jan 14, 2022 at 5:21
  • 5
    Also note that outside of a data center context, the key is not necessarily stored anywhere; it may be derived from a passphrase.
    – marcelm
    Jan 14, 2022 at 10:58
  • 1
    Google has a pretty good whitepaper addressing this question: cloud.google.com/security/encryption/default-encryption/… (I don't expect this is much different from other cloud providers of similar size). Jan 15, 2022 at 6:11

8 Answers 8

31

Yes, it's worth it, by far.

Computers get stolen. If the hard disk is encrypted, the thief ends up only with hardware, and hardware is cheap to replace. If the disks aren't encrypted, the thief has the hardware and the data. Depending on what kind of data, the company can lose intellectual property, industry secrets, HR data, and that can translate into huge fines (or dead people, if the data is the real names of CIA operatives).

USB devices are easy to forget, or to misplace. If they are encrypted, and the key is stored on the computer, there's nothing on the drive that can be read.

Full disk encryption indeed keeps the key on the system, but the key is password protected, and the password is not on the system. Bruteforcing the password is possible, but depending on the length of it, can take way more time than the data is interesting (think taking 1000 years to crack it).

High security systems keep the keys on a TPM or a smartcard. The first has pretty secure settings, and capturing data from inside a TPM is not remotely easy to achieve. And a smartcard usually is not stored with the computer, and usually is protected by a PIN and auto erases itself in case of a bruteforce attempt.

There are LUKS settings (for Linux computers) that don't even keep the encrypted header on the disk, but it resides on a USB drive. In the case of theft, there is nothing to be bruteforced, because the header is on another hardware, probably with the user.

3
  • yes my LUKS setup has the 2048 bit keys stored in the /boot partition. That itself has to be unlocked with a password (this is something grub supports). No doubt the password is less secure than the keys that it grants access to, but if I wanted to up my security I could replace that small partition and put the keys somewhere else, without having to reformat my /home and / partitions.
    – Rodney
    Jan 15, 2022 at 10:09
  • "but the key is password protected, and the password is not on the system". That's certainly true for personal devices, but for a server that has to boot and start independently of a login, the key has to be accessible to the system somehow. If you have access to the system you can in principle get the key and any measure to protect it is just obfuscation. No? Jan 31, 2023 at 11:52
  • For servers, you can store the password on the TPM. If we consider the TPM as a separate system inside the system, the point holds.
    – ThoriumBR
    Jan 31, 2023 at 22:29
24

In addition to what @hft and @ThoriumBR mentioned, specially in context of a datacenter, encryption makes it easier to discard the drives when they fail and need to be replaced.

If full disk encryption is not used, discarding drive would require either securely wiping the entire drive (which would be impractical for a failed drive anyways) or effectively destroying the drive so that no data remains recoverable, which requires specialized equipment and trained people to do it. While this may not be a massive issue (as pointed out by others below), there would still be a risk that the drives get lost/stolen before they are destroyed, or that they are not shredded properly and some data may remain recoverable afterwards.

If encryption is used, it is much more simple. You just have to make sure the key has been securely deleted and then the drive can be thrown away. Since the key is usually stored in a separate hardware security module (and in some cases, protected with a password), deleting it is trivial.

4
  • 2
    I'd think for a large datacenter it would actually be pretty trivial to have some big dumb machines on site that will simply grind all failed drives to powder, or incinerate them. Jan 14, 2022 at 11:42
  • Destroying keys is the preferred method of data destruction, but data centers usually have secure destruction processes for hardware disposal anyway. The operators will record the serial numbers of the hardware being destroyed, then drop them into a shredder, or into a locked bin for later disposal. (Incineration would produce highly toxic smoke, so that's not normally used.) A quick search for "data center disposal" will yield a number of companies that provide specialized disposal equipment or secure recycling services. Jan 14, 2022 at 16:35
  • 2
    @leftaroundabout Speaking for a medium-sized datacenter, we contract with a local company for media shredding. Costs about $500 (US) for them to come on-site and shred several thousand disks plus a moderate number of tapes and miscellaneous media. Serial number scanning is included. Doing this every few months is not a major effort or cost. Our biggest issue is finding a secure location for the disks to be stored before they're shredded.
    – doneal24
    Jan 14, 2022 at 18:53
  • 1
    Defence in depth - discard the key and destroy the media. Adds a little extra protection against incompetent or dishonest disposal staff, for very little cost. Jan 15, 2022 at 14:08
8

Long story short, against a decided attacker with proper means, it'll be useless. The question would be about your threat model.

The decryption key (or its encryption key) will typically be stored on a different machine, in a different location. The machine storing this key will often only have that role, and will be more guarded. That means if somebody steals a bunch of machine from one place, including yours, your data is safe. They would need to steal a machine from another location, likely well guarded. That makes it worth it against theft. And of course from a liability point of view as outlined in other answers.

6

But regardless of what type of encryption is being used, the key (or some other method) also has to be stored somewhere - readily accessible for decryption. So, wouldn't it be simple for someone to just undo the encryption? Given they already gained access.

A secure implementation will try to keep that problem from being simple to solve.

Let's look at VMWare's vCenter as one example. Say your cloud provider uses vCenter to manage all their virtual machines. When you click on the button that says "I need a Fedora version 35 server with 40GB disk", your provider is using vCenter to provision it. vCenter tells a vSphere instance to spin up a virtual server for you. When it creates your virtual disk image it will encrypt that image with a unique key. That key does not come from vCenter; vCenter requests that encryption key from a key server.

The key server is a completely different product running on specially protected hardware, and it keeps the database of encryption keys. That database is also encrypted, of course. The Key Encrypting Key (KEK) is the master key to the database, and it is stored in yet another system called a Hardware Security Module (HSM). The HSM encrypts the KEK, and is designed so the KEK never leaves the HSM. Instead, the key server sends the encrypted database record with your key to the HSM and asks for it to be decrypted; the decrypted key is then returned to vCenter, which passes it to the vSphere instance hosting the VM, decrypting its disk image.

The HSM is designed to be extremely sensitive to detecting tampering, and if it is disturbed it will instantly erase the special memory where the keys protecting the KEK are stored. Both the key server hardware and the HSM hardware are protected by physical armor and locks, which also contain tamper detection systems that will zeroize sensitive memory. The key servers and HSMs are also not normally managed by data center personnel. They may be locked in a special cage in the data center. To set them up and get them operational they require various security officers to show up with the needed keys and passcodes to unlock and initialize them.

All the intermediate machines that handle the key do so in memory, so the key stays off of disks and out of swap space. The disk image key itself is never exposed internally to the VM.

Now, let's look at possible attacks:

  • A running VM is as vulnerable as any other machine, so it needs to be defended or the attacker can extract the data from it directly.
  • To steal the VM's entire disk image, the attacker needs to attack the vSphere instance hosting the virtual machine while it has the key in memory, or the image will remain encrypted.
  • To steal all disk images, the attacker would have to attack vCenter to steal the authorization used to request the disk keys from the key servers.
  • To steal all keys, the attacker would have to attack the key server.
  • And to steal the KEK, the attacker would have to defeat the HSM's protections.

Some of those tasks are easier than others; but few are what you might consider "simple".

2

The major downside to at-rest encryption where the key is also stored is user confusion and moral hazards.

Imagine I have a laptop full of private patient data. I use full disk encryption - but the password is written on a post-it note stuck to the laptop. Technically the data is encrypted - but for most practical purposes, it is as if the data is unencrypted.

If my laptop gets stolen, and my employer needs to announce the breach, will they want to make it clear the data was effectively unencrypted? Or will they decide it's better for the company if they describe the data as fully encrypted?

2
  • 4
    The answer to your mythical quandary is to announce the technical truth: the data was encrypted per HIPAA rules and company policy, but the key was compromised and the data should be considered exposed. It then becomes a different question as to how the key was compromised: did the company provide the laptop with the password carelessly stuck to it? Or did mjt copy the password from the company's secure server and stick it to the laptop in flagrant violation of company policy? That question would be at the core of upcoming lawsuits. Jan 14, 2022 at 18:28
  • 2
    None of them @JohnDeters! The company IT gave mjt the initial password in a post-it, and per company policy he was required to memorize it and then eat it. However, although mjt was given the policy book he never read it. Moreover, he claims to have bad memory and was thus unable to learn it despite having been using this laptop with the same password for two years.
    – Ángel
    Jan 16, 2022 at 1:27
1

There's more to disk encryption than just this, but I'll stick close to your question:

"readily accessible" does not necessarily mean the same thing for an authorized user and an attacker. For example, imagine the password is written on a post-it right next to the monitor. That's "readily accessible", right? Well, no it's not if we're talking about a remote attacker hacking in over the network. He has no way of looking at that post-it note.

So the answer depends a lot on your threat model and how exactly the keys are stored.

0

Auditing and rate limiting

In addition to all the concerns mentioned in other answers, two aspects especially relevant for data at rest encryption for sensitive corporate data is auditing and rate limiting.

While a key has to be usable, it does not have to be accessible, you can keep it in a separate system which allows explicit control about how and when the key is used - the main key is not ever leaving the separate secure system, it just gets used by it to decrypt something if the decryption fits certain criteria and deny decryption in certain cases.

Let's assume the attack scenario where attacker has full control of a system which has have sensitive data encrypted at rest, which requires a key to access - but the key itself is stored in a separate secure system. If the system could use the data in normal operations, then it generally has ability to use the keys required for that, and so the attacker can also gain that ability. However, the key system (a HSM might get used, and often you'd have sub-keys - I've seen systems which store a separate random key for each sensitive DB row, all encrypted by a main key kept on a HSM) can be configured to verify and log what data decryption gets requested, which can then raise alarms in monitoring if the operations are unusually frequent or simply unusual - in fact, for some sensitive data (e.g. some signing certificates or backup credentials for some machines) every access can flag a monitoring alert, and in this way you can ensure that access of this at-rest encrypted data is impossible without raising such an alert.

Also, if the normal usage pattern requires rare access to individual rows of sensitive data, where only a small fraction of all sensitive records are accessed each day, then simple rate limiting can be configured to make it impossible for an attacker to decrypt the whole dataset before they get detected, limiting the impact of a database breach.

0

The thing to remember is that not all compromises are equal.

If a system is totally compromised, then the attacker has the same level of access as the system itself, and can readily decrypt the data.

But not all compromises are total. One illustrative example is the 2013 Adobe hack. A large number of encrypted passwords were exfiltrated, but encryption keys were not. Whilst it is clear that there were some significant failings in Adobe's security, encryption keys appear to have been protected against this attack.

Which is a long winded way of saying the usual: that it depends on your threat model, and that it can be a valid defence in depth strategy, where the usual caveats about defence in depth apply (many weak defences are not a substitute for a strong defence, and you need to consider the additional surface area your additional defences add).

You must log in to answer this question.

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