When I started a few days ago with the follow-up diary entry on the original coldboot entry, I was hoping to provide an overview that e.g. security officers could use to make sure their users knew how to use the encryption products installed on their machines in order to ensure that the intended protection is actually achieved. But we're faced with a situation where we need to rely on contradictory claims we have no way to validate. Hence, to avoid spreading false information, I'm pulling the overview in the guidance diary, and will change it into a list of vendor reactions.

Only a deep technical audit (reverse engineering or source code) of all these products could be able to provide the needed answers, but we just don't have the resources to do that now.

Instead I've decided to pass on the hard to answer questions for your vendors, if I cant pressure them, collectively we still might cast our vote for honesty and openness.

For the typical pre-boot whole disk encryption, without added hardware:

• How is/are the key(s) protected in a machine that's fully off ?
  Know that the key is a cryptographic key (e.g. an AES key), it's a sequence of bits, not a password you type. It needs to be stored somewhere, somehow. Know how it is protected.  I strongly dislike any answer including words like "proprietary", "confidential", "obfuscated" etc.
• How is/are the key(s) protected in a machine that's running and actively used ?
  Once the machine cleared the pre-boot, typically "the key is in the lock", or the cryptographic key is stored in RAM, for use by the drivers. At this point, we expect the coldboot attack can be performed. Any vendor claiming not being vulnerable at this stage should explain how they never have a key in RAM that they use to encrypt and decrypt disk blocks.
  GUIDANCE: machines where control is lost in this state, are most probably vulnerable.
• How is/are the key(s) protected in a machine that has its screen locked ?
  Once a user leaves his machine for a bit of time a screen saver might kick in and lock the machine. By default this does not always mean the keys are removed from RAM (mostly they will not be). It is not trivial to remove the cryptographic keys at this point as they need to be retrieved and e.g. programs can continue to run (which might require access to the disk ...)
  GUIDANCE: machines with a locked screen are typically not protected by the disk encryption due to the coldboot attack, unless your vendor specifies exactly how they remove the key(s) while allowing the processes to continue to run.
• How is/are the key(s) protected in a machine that's asleep ?
  Once a user closes his laptop one of the actions possible is to sleep the machine. Basically the contents of the RAM is kept in place. Since this is a mode users would typically use to transport machines, attention needs to be given to this mode. While the processes are not running anymore, there might be some way to remove the keys from RAM before sleeping the machine, and upon waking the machine first prompting the user and restoring the keys from their protected storage.
  GUIDANCE: for most products of the pre-boot type, the guidance you need to give your users is not to use sleep  mode at all (if you can block it, or replace it with hibernation, that might be a good option to consider).
• How is/are the key(s) protected in a machine that's hibernating (RAM+hibernate file)?
  This might seem easier: the machine first writes its status (including a memory image) to disk and then powers off. The encryption software might erase the keys from RAM before powering off, making the machine more safe in the first minutes. If it doesn't erase the keys from RAM, they will eventually fade anyway, allowing for a short window of vulnerability to the coldboot attack (up to a dozen minutes or so).
  An interesting part is how the memory image is managed: it potentially contains the key from RAM too! Similarly swap files (or partitions) can contain keys just as well.
  GUIDANCE: much depends on the answers you get from your vendor, there seems more difference between products in this respect, so do ask them how their product works. Determine trust and risks afterwards.

For solutions that add hardware (e.g. TPM, USB tokens, dedicated hardware, ...) details are needed and the questions need to be adapted to those details.

For solutions that only encrypt a directory or a file, the issues are slightly different , still focusing on the different states and knowing how the key(s) are protected, how the processes using the data continue to run etc. is the answer you seek in order to build the guidance for your users.

All other products that you use that handle cryptographic keys could/should be examined in the same fashion, it's not just disk encryption that's at stake!

Contacts at vendors claiming full invulnerability or extremely unlikely scenarios are not good sources of information to gather data from to use in evaluation your risks, seek more technical answers before you believe their evaluation blindly.

Finally, with frustration, I need to express my sincere regrets to the people of those vendors who were cooperative in providing information to questions such as those above; to the readers contributing information and to all those hoping we could get the overview stable and correct.

--
Swa Frantzen -- Gorilla Security