Could private keys in memory be inadvertently sent to swap? (disk)

[agent13]

If you have Bitcoin-qt open or another client etc, is it possibly Linux might swap the memory (and keys) to swap? (and therefore to disk). Even though you might have wallet.dat encrypted, could the keys inadvertently be dumped to disk? How could this be avoided? Perhaps just have a lot of RAM so swapping is not needed? This could technically even occur with javascript key generators correct? Is it possible to zero-fill the swap partition after exiting the client?

[moderate]

Obvious solution: remove your swap partition(s).

Anyway, isn't this the kind of attack that if you happen to be vulnerable to it then you're already vulnerable to a lot of other potentially more dangerous things ?

[gmaxwell]

is it possibly Linux might swap the memory (and keys) to swap? (and therefore to disk)

We mlock the memory used for private keys, however there could be a mistake someplace or another, so encrypted swap is still advisable— and very easy to do under linux.

[oleganza]

On Mac it'll be just enabling FileVault2 - full disk encryption. And, preferably, using sandboxed apps.

[FreedomDealer]

A similar problem is a core dump (after a crash, for example), when memory content ends up in log files.
A solution is full disk encryption. On Linux, you can encrypt a partition using LUKS and create your root, swap, home, etc. on top of that as logical volumes using LVM.

[moderate]

A similar problem is a core dump (after a crash, for example), when memory content ends up in log files.

As a reminder, in production you shouldn't be producing core dumps. Either disable the generation during kernel compilation or through utilities (like ulimit).

[agent13]

I like using Ubuntu with Bitcoin-QT. I also play with bitaddress etc offline. The default Ubuntu installer creates a swap partition. It provides an option to encrypt the user folder, but not swap. Might someone have a link to a how-to to resolve this concern?.. ie, encrypt the swap partition? Or, what might be the best way to tackle this in Ubuntu?

Thanks.

[StarfishPrime]

We can expect to see increasingly creative attacks with btc >~1K USD. There are many attack vectors left to be exploited.

Code should never keep unencrypted keys in memory longer than absolutely necessary and overwrite any instances as soon as possible. Scanning multiple GBs for likely keys is trivial. It's not necessarily difficult for malicious code to cause a core dump - not all OS's are created equal.

One thing we can definitely be sure of - the "best" minds of the eastern bloc are already working on it.

[Peter Todd]

A similar problem is a core dump (after a crash, for example), when memory content ends up in log files.

As a reminder, in production you shouldn't be producing core dumps. Either disable the generation during kernel compilation or through utilities (like ulimit).

Note that under Linux you can in fact do selective core-dumps that skip some sections of memory.

This is usually used when an application has large sections that are not relevant for debugging, but could prove useful to keep private keys out of disk as well.