There are times when a user of a free and open source operating system like FreeBSD or Debian GNU/Linux might encounter a warning or error message that looks something like this:

“Warning: using insecure memory!”

A likely moment might be the first time one uses GnuPG, because it’s helpful with the scary warning messages like that:

Yes, I intentionally changed settings on a (secured) machine to use “insecure” memory just to show you how such a message might look. See the sacrifices I make for my readers?

One might ask, “What does this mean? Does my computer’s RAM need a therapist?” Of course, the second question would just be a joke. I hope so, anyway. The first question is somewhat more serious, however. That and nineteen other questions, have been answered below.

What does it mean?

So-called “insecure memory” is used when something stored in memory might be written to non-volatile storage, as in the case of data being swapped out of RAM to the hard drive because too much memory is being used to keep everything in RAM.

Why is it insecure?

Data in your swap partition or swapfile (what Microsoft calls the “pagefile” in its Windows OS) is not automatically lost when you shut down your computer. Something “swapped out” of RAM might thus be retrieved later by someone who has physical access to your computer, even if it has been turned off, while something that was only stored in RAM theoretically “goes away” irretrievably when there is no longer any power maintaining the data in memory.

Why does it matter?

When working with encrypted data, you need to decrypt it at some point so that you can do something meaningful with it. Similarly, passwords should hopefully never be written to disk when you enter them at a prompt for authentication. Such things should only exist in RAM for the minimum necessary time to do what needs to be done, while the encrypted form is all that ever gets stored on disk.

Does this mean that RAM is secure and the hard drive isn’t?

Not exactly. It means that there are some very real, immediate security issues related to storing sensitive data on the hard drive and other long-term storage devices without encrypting it that do not apply to volatile memory. RAM does have other problems, however:

  1. For one thing, while people imagine that turning off the power immediately clears RAM, the truth is that data can persist for several minutes — retrievable by someone with the correct skills and forensic tools.
  2. Another problem arises if you use solid-state storage devices (like a USB flash drive) to extend your memory capacity (such as via MS Windows Vista’s ReadyBoost), because such storage devices are non-volatile. That means they do not automatically clear after cutting power to the computer.
  3. In addition, if a malicious security cracker gains access to your computer either via the network or in person while it is on, unencrypted data in RAM may be accessible.
  4. Finally, more esoteric tricks (like van Eck phreaking — perhaps a subject for another article later) can be used to access data in RAM without having direct access to the computer, either physically or over the network.

Can’t we just encrypt RAM?

Theoretically, yes. On the other hand, that wouldn’t be very useful. If all your sensitive data in RAM was encrypted, you wouldn’t be able to read it. Security can’t be perfect — but if you’re smarter about it than the guy trying to break in, it can be secure enough.

Can I make sure I don’t use “insecure memory?”

Yes, you generally can. As an example, we’ll address the fact that on some systems non-root users do not have permission to “lock memory pages” to prevent the OS from writing data to disk from volatile memory — so you might get an “insecure memory” warning when using GnuPG. The way to fix this is to “setuid root” your gpg binary.

I’ve heard “setuid root” is bad — but what does it mean?

When a program is “setuid root”, this means that running it does so with root privileges. In general, that is not a very good idea for security purposes, but GnuPG is written such that when the gpg utility runs, it drops any root privileges as soon as the memory allocated to the task you are performing with GnuPG is “locked” so that it cannot be written to disk. If you don’t believe me, you can check the source code, since it’s open source software. I haven’t checked it personally, but I’ve talked to people who have.

How do I actually make gpg “setuid root?”

It’s pretty simple, really. Assuming your gpg binary is located at /usr/local/bin/gpg2 as it is on FreeBSD, you can “setuid root” with these two commands:

  # chown root /usr/local/bin/gpg2

# chmod u+s /usr/local/bin/gpg2

The first command makes root the “owner” of the gpg binary (in case root didn’t already have ownership of the file). The second makes the program run with the privileges of its “owner” no matter who started it up.

Do I need root access for those commands?

Yes, you do. If you do not have root access to the machine, you can ask whoever does to do it for you, obviously. On the other hand, if there’s someone else with root access on a system where you do not have root access, you may want to rethink using encryption software there — unless that person is allowed to see unencrypted copies of everything you’re encrypting there. After all, such a person has enough access to employ all sorts of dirty tricks (like keyloggers, for instance) to capture data you don’t want him having, such as your GnuPG passphrase.

Can I make the warning go away on Microsoft Windows?

Of course you can! You can use the --no-secmem-warning command line option, or put no-secmem-warning in your gpg.conf file, to tell GnuPG that you don’t want to see the warning.

Does that actually stop it from using “insecure memory?”

No, sorry, it doesn’t. All it does is stop the warning from appearing. There are ways you can improve security in this matter, but you cannot achieve the same level of security on MS Windows that you can on Unix and Linux-based systems. In all my years of IT security work, I have never discovered a reasonable way to lock memory pages against being swapped to disk on MS Windows.

It’s possible you may even get a version of GnuPG for MS Windows that doesn’t give you that warning in the first place — but be aware that doesn’t mean you aren’t using “insecure memory.”

Does that mean I shouldn’t use GnuPG on Microsoft Windows?

Yes and no:

  1. No — it doesn’t mean that. This is not a problem specific to GnuPG. This is a problem with any tools you might use to encrypt and decrypt data on your MS Windows system. The problem is that decrypted data in RAM (as well as passwords, et cetera) cannot reasonably be prevented from being written to the swapfile (including SSH, SSL, and so on), and not any issue with GnuPG itself. It means that, if you have a better option, you shouldn’t use any encryption tools on MS Windows. On the other hand, using GnuPG for encryption with MS Windows is better than never using encryption at all.
  2. Yes — it does mean that, in a manner of speaking. It means that, given a choice, you should use an operating system other than MS Windows when working with encrypted data. If you aren’t given that choice, though, see the last sentence of the No answer above.

Can’t I just clear the swapfile before shutting down Microsoft Windows?

Yes, you can. In fact, you can make MS Windows do it automatically, using a registry setting. This approach has some shortcomings, however, that render it significantly less “safe” than simply never writing sensitive decrypted data to the swapfile itself (in addition to degrading system performance):

  1. Data on the hard drive is usually easier to access when you’re not supposed to do so than data in RAM. This means that if someone has compromised system security, but doesn’t have some tool in place to log keystrokes and otherwise intercept decrypted data you’re using, it can be quicker and easier to get at sensitive data in the swapfile before MS Windows deletes it than in RAM.
  2. MS Windows cannot overwrite an “active page” in a swapfile. That means that it only overwrites the data when you’re done with the application that created the memory that was written to the swapfile in the first place. That assumes both that there isn’t a memory leak that lets the data in the swapfile stay where it is even when you’re done, and that MS Windows overwrites the relevant pages in the swapfile right away — which it often won’t, thus prolonging the life of those pages in the swapfile. There are rumors that MS Windows Vista has the capacity to clean up after memory leaks where previous versions of MS Windows could not, but I wouldn’t bet the security of my encrypted data on that. In matters of security, the base assumption should be that the system isn’t secure enough, and only with evidence should you revise that in a positive direction.
  3. This technique’s effectiveness depends on the assumption that MS Windows will get a chance to overwrite the swapfile. If your computer loses power suddenly, or the OS crashes (a very real danger), it may not get a chance to overwrite the swapfile with zeroes.
  4. All this technique does for you is overwrite the relevant sectors of the disk with zeroes. This means that it still might be possible to recover data from those pages in the swapfile. Multiple overwrites with random data would make it more difficult, but it might still be possible, depending on the skills and resources of whoever is trying to recover your sensitive data — but, sadly, this technique doesn’t lead to multiple overwrites with random data. Of course, just overwriting once with zeroes is better than “deleting” as when you delete a file from the drive in Windows Explorer, because that kind of “deleting” doesn’t overwrite the data at all — it just tells the file index on the drive to forget the data is there so that it can be treated as empty (and overwritten with other data as needed) later.

Can’t I just allocate some RAM for a “ramdisk” and put my swapfile in that?

I suppose so. You could do so on a Unix or Linux-based system, too. That completely defeats the purpose of a swapfile, though. A swapfile is meant to provide a place for data in memory to go when RAM is full. Creating that ramdisk removes that much memory from circulation, making it fill up faster, so that by the time you would be writing your first bit of data to a swapfile on the drive you will have filled up both normal RAM and the ramdisk swapfile. If anyone suggests you should use a randisk swapfile, he or she is probably either incompetent or making a joke.

Can I eliminate the swapfile entirely?

Yes, of course. This might create problems if you ever need more memory than you have in RAM, however. Make sure you have lots of RAM before doing this, especially if you are running a recent version of MS Windows (which will of course require a lot of RAM).

How else can I mitigate the risk?

If you have more than one computer where you will be using GnuPG, you could use it for the more critical and important sensitive data on a non-Microsoft OS that allows you to lock memory pages against being written to disk, and with a different set of keys (to protect the passphrase) use it only for less critical and less important senstive data on the MS Windows machine. This assumes, of course, that you have that option. If you have to use GnuPG on MS Windows for some reason, chances are good this isn’t much of an option. Still, separating as much sensitive data from the system without the ability to lock memory pages against writing to disk as possible is a good idea.

What is the best way to protect myself on Microsoft Windows?

A high-quality full disk encryption tool like TrueCrypt can be used to keep your swapfile (as well as everything else in the same partition) encrypted at all times, as long as it is on the disk. Of course, it all gets decrypted as it is brought into RAM so you can use it, but anything written to disk in an encrypted volume is encrypted before it is written to disk, including memory pages sent to the swapfile. TrueCrypt is a handy tool that way, and can actually make other encryption tools like GnuPG almost as well secured on MS Windows as they are on systems that can lock memory pages against being written to disk.

That’s my take on the best answer. If, for some reason, TrueCrypt (or a similar tool) is not an option for you, it may not be the best answer for you.

Is this “insecure memory” thing a common problem?

It is far more common than you know. Very, very few encryption and decryption programs bother to tell you that you’re using “insecure memory” when they do so. There are several reasons for this:

  1. MS Windows applications use “insecure memory” all the time, so there’s not much point in mentioning it, generally. There’s no way to fix the problem on MS Windows other than encrypting the swapfile (which, by the way, tends to slow it down quite a bit).
  2. The vendors for some supposedly “secure” software don’t want you to worry your pretty little head when there’s a security problem, especially since that might affect sales.
  3. Most programmers aren’t even aware the “insecure memory” problem exists. Thus, there’s a lot of cryptographic software that doesn’t provide any means of locking memory pages against being written to disk at all because the programmers simply didn’t know any better. Now, hopefully, you know better.

How likely is this stuff to be a problem?

As long as you maintain strict physical control over your system and ensure that network security is tight as a drum, you should be okay. On the other hand, there’s always someone out there that can figure out how to get around your security. You just need to stay on the right side of luck — and that’s not just limited to systems using “insecure memory.” It’s best to avoid the “insecure memory” problem, in case someone gets past your other defenses.

Why do you keep putting “scare quotes” around “insecure memory?”

“Insecure memory” is kind of a misnomer, but it’s what everybody calls it. I use the “scare quotes” to indicate that “insecure memory” isn’t a perfect term.

A more correct term would be unsecured memory. The problem with what is called “insecure memory” is that it has not been secured against sensitive data being written to disk as plaintext — thus making it unsecured.