Suggestion: Lock memory to avoid key/cleartext compromise

[mcorb]

When a long-running gocryptfs process is paged out of memory the plain decrypted key stored to disk. With modern SSD drives and wear levelling the key could remain forensically recoverable for months or years.

This can be mitigated using an mlock facility like memguard (the go equivalent of libsodium), which manages memory slices that are guaranteed not to page out.

it looks like memguard could be dropped into the bPool interface without much work. You'd just need to make sure that the user password and decrypted key are only ever stored in memguard-managed memory.

(For bonus points it might be interesting to use the facility for cleartext content buffers too, ensuring that the gocryptfs process doesn't compromise confidential user data either.)

[rfjakob]

Good point, and the memguard library looks pretty good! However, most of the times, we don't store the key, the standard library does, like here:

gocryptfs/internal/cryptocore/cryptocore.go

Line 89 in f594797

goGcmBlockCipher, err := aes.NewCipher(gcmKey)

In this case there is not much we can do about it.

[rfjakob]

But due to your suggestion I have just pushed 0c52084 to clear the masterkey as soon as we can. We kept an unneccessary copy around.

[mcorb]

Thanks @rfjakob. This mitigates a little and at least makes it explicit. If the standard library is using the standard allocator I guess it's inevitable bits of key are going to get swapped - pity.

[rfjakob]

The only solution to this, at the moment, is to either disable swap or use an ecrypted partition.