Should a full disk encrypted hard drive on a live system be considered encryption at rest?

Question

If you are specifying requirements that a certain classification of data be encrypted while at rest (on storage), should the requirement be considered met if the data is stored on an live (turned on) system where all storage media has full disk encryption?

The storage is encrypted and will be protected if the system is turned off (let's ignore evil maid type attacks for the moment or freezing the memory to capture the key); however, while the system is on, the data is at risk because of the possibility of key loggers, malware, or other exposure that can result from security issues caused by the fact the system is simply active.

For example, if a laptop has full disk encryption and is turned on or it is in hibernation or sleep mode, should that data be considered encrypted? This has implications for protecting data on the front end and considerations in data breach reporting. If a thief stole a system which is not totally shut off, it may not be possible to gain direct interactive access due to password restrictions and brute force lockouts, but there might be network or hardware attacks which could allow for remote exploitation to gain local access, and thus to the "encrypted" data.

A more clear case of encryption at rest would be unmounting a encryption container or storing the file in an encrypted zip file (using a strong algorithm of course, like AES versus the weaker password protection on basic zip files). More obvious would be removing the hard drive or usb-connected media where the data is stored. Because the data would have to be actively unencrypted, this would seem to fully meet requirements for encryption at rest.

Therefore, what factors should one consider if evaluating full disk encryption as meeting encryption at rest data requirements?

Answer 1

For my company at least, full-disk encryption isn't seen as adequate for 'data at rest' requirements, as on a live system the data can de accessed without providing a key or any additional authentication information. When relying on FDE, if an attacker was able to get in, at that point it's extremely easy to steal data, and do so quickly as no other knowledge is required.

We require that all data at rest be encrypted with AES (by various means) or via PGP, without regard to the use of FDE. This way just having access to a running system isn't sufficient to retrive protected data; additional knowledge (passwords, keys) are required.

We do require FDE on any system that leaves our facilities, but more to protect ancillary information that could help an attacker (email, notes, etc.) or any information stored in violation of policy.

Answer 2

In general, the term "at rest" is a complement to "in transit", and data is usually specified to be in one state or the other. Data "in transit" is being actively communicated, usually through a network somewhere. Data "at rest" is sat on a hard drive or in RAM, usually within a relatively safe boundary.

The reason we make these distinctions is that it makes it easier to classify the security requirements for data. What applies to data in transit doesn't necessarily apply to data at rest. For example, you want end-to-end encryption (e.g. SSL) for transmitting a password to a server, but you want hashing (e.g. bcrypt) for storing that password on-disk at the server.

So, a general rule of thumb for deciding is "am I holding the data, or am I communicating the data?" In the case of 99% of drive encryption schemes, it should be considered to be at rest.

Answer 3

The classification of data as being "at rest" or "in transit" is just a usually convenient tool for risk analysis; but there is no rule which states that data is necessarily 100% at rest or 100% in transit, with a clean separation. The Lord did not boom out across the skies "let data at rest and data in transit be separate". Categories are a human creation which cannot pretend to universality.

What is useful to think about, when dealing with encryption, is who has the power to decrypt, which often trickles down to the whereabouts of the keys. Data "at rest" is data which will be accessed later on, with no arbitrary limitation on the "later on", so the decryption keys must be somehow stored permanently (the storage may be a smart card, a human brain, a file on a smartphone, a piece of paper... but it exists in a tangible form). On the other hand, data "in transit" is meant to be decrypted almost immediately, by a system which has the decryption key in RAM only and will forget that key almost immediately afterwards, making it immune to ulterior key theft. In that view, an encrypted disk is always "data at rest". But, with the same definition, a SSL connection is also "data at rest", unless a "DHE" cipher suite is used, in which case it becomes "data in transit" (because of perfect forward secrecy).

Another view on the subject is that data is properly secured when "at rest" if it is encrypted with a key which is not stored on the same system. Your laptop with an encrypted disk fulfills this requirement if (and only if) it is shut down: the decryption key is the password, which is then in the head of the human user, not in the laptop. If the laptop is powered on, then it is not "properly secured" (still "at rest", though).

Answer 4

Full disk encryption isn't really encrypting data at rest. Data is at rest when it is sitting on the hard drive, but it is only encrypted in an FDE situation when the drive is offline. As long as you have the drive mounted for access the full disk encryption is not protecting it. FDE is good for stolen drives, it does nothing against hackers or malware with access to the live system.

Answer 5

It does depend on your definitions. "at rest" v.s. "in transit" are pretty meaningless without a specific threat model.

@Polynomial suggests that "at rest" means the data is not crossing a boundary into a less secure space -- it is "safe". But @Adam and @Tom suggest that a mounted filesystem is not as "safe" because the keys are in RAM -- a less secure place than your brain or a HSM. It is vulnerable to any attack that can disclose encryption keys stored in RAM. (Most of these require physical access.)

If you are working on a laptop in a hotel in San Diego, hoping to get to Chile tomorrow, and you are worried about the FBI breaking down your door, the data is definitely "in transit". Working on the same laptop locked in a TEMPEST cage with no network access after you get to Chile is "at rest".

Consider these attacks that the FBI may use:

Search for "Firewire memory dump". I imagine that this is possible with any device that can do big blocks of DMA. JTAG might provide similar access to some devices.

QubesOS attempts to use IO/MMU to stop this, but support is spotty at best in current hardware. Tails has an emergency shutdown feature that should quickly wipe the RAM when a certain key combination is pressed or USB drive removed. This seems to be an area of active research and might not always be reliable.