Risks of encryption keys contained in a memory dump after a crash?

Question

Assuming a full disk encrypted system where non-volatile storage is encrypted.

While the system is running, in case of a crash and memory dump, e.g. plugging a USB drive causing an IRQL_NOT_LESS_OR_EQUAL error, what are the risks that the encryption keys are contained in that memory dump file?

As a variation, assume an environment where you have an encrypted container sitting open, and the system crashes at that moment.

In any scenarios where there's something encrypted on disk but decrypted on-the-fly while the system is running, and a system crash occurs, are there risks that the memory dumps contain encryption keys or something that would lead to them ?

Local case:

The above scenario just happened to me, and I have done a local analysis.

I opened %SystemRoot%\MEMORY.DMP with a hex editor, and looked for passwords or passphrases but didn't find them. However, is it possible that they are still contained in another form, or that there is something leading to finding them out?

Answer 1

Absolutely it's possible that the memory dump could contain keys. If all programs follow good programming practice (clear keys immediately after use) that reduces the likelihood, but there's nothing that a program can do when doing encryption/decryption in software to 100% prevent keys from being in memory. After all, a key has to be in memory to perform encryption/decryption and if as soon as the key is put into memory the operating system crashes there's nothing the program can do about the key at that point.

Answer 2

The risk would be minimal if your memory dump is a core dump. Your error code is a logical error, not CPU fail or memory management error, so the core dump includes only kernel memory. (Kernel stacks, cpu context, error message, loaded modules, etc.) There is a very low possibility that your passphrase (usually encrypted) is stored in the kernel stack.

BTW, you could analyze .dmp files with WinDbg.

Answer 3

Memory dump may contain “Key material”, i.e. not the key as an array of bytes for AES_Init() API but the key expanded to memory structures. For example, a “Key material” can be a mapping of encryption key bytes into internal arrays of encryption code/library, i.e. a processing state of the key. Having such an internal state image, it is easy to reconstruct a key into its normal form. To identify such a key materials within a memory dump, you need to search for key derivatives, for each specific algorithm.