Security mechanisms for protecting the process memory?

owolf

These are general questions about 1Password. The questions are plattform independet.
Are there any mechanisms to secure the process memory like encryption?
Is there any mechanism that prevents the process memory from being swapped to disk?

RichardPayne

No, because those things are not possible (short of disabling the swap file entirely).
1Password does try to minimise any exposure by only keeping decrypted data in memory for the shortest possible period. The reality is though that if you vault is unlocked then your vault's master key must be in memory and so, if an attacker gains enough access to read another process' memory (admin access basically) then there is nothing to can be done to stop them finding the key and then decrypting the rest of your data.

The key thing here is to keep your system as secure as possible. Breaking in to a PC and gaining admin access is not easy unless the user does something stupid.

svondutch

Are there any mechanisms to secure the process memory like encryption?

We do not encrypt the process memory because such techniques are known to make anti-virus scanners very upset.

That being said, here are a few things we do:

1. We do not keep your master password in memory. Your master password is available to us when you type it into the unlock window. Immediately after we have used it to unlock your vault, we zero it out.
2. Your encryption keys are in memory for the shortest life span possible. When you lock your vault, we then zero them out. Because 1Password is designed to automatically lock itself, your encryption keys should never be in memory for any longer than a few minutes.

At some point, anything that is decrypted or waiting to be encrypted is stored in memory in plain-text, and this includes your master password and your encryption keys. This is the weakness of personal computers and the best we can do is zero them out as soon as possible.

That being said, here's something else we do. We use ASLR, as can be seen by Process Explorer:

ASLR ensures that 1Password isn’t using a predictable address space in memory that malware could attack.

For the rest, we rely on the operating system to forbid processes from accessing each other's allocated memory and hope for the best. We must trust the operating system for not giving it away to third parties. The operating system is our friend, because if the operating system is an enemy then all bets are off.

The bottom-line is that passwords in memory are no safer than what the operating system allows. If you're super concerned about this, then my advice is...

1. Encrypt your harddrive. For example: use TrueCrypt or VeraCrypt. This avoids memory leaks through hibernation (when the whole RAM is written to disk).
2. Do not use personal computers. PCs are designed to run several processes (on the same CPU, sharing resources, including cache memory) which are hostile to each other. Use dedicated hardware that is designed for perfect peace and isolation.

jpgoldberg

Hi @owolf. That is a great and tricky question.

I would like to add to others have said, by talking about this at different levels.

I'm going to quote myself from a blog post about keystroke loggers:

I have said it before, and I’ll say it again: 1Password and Knox cannot provide complete protection against a compromised operating system. There is a saying (for which I cannot find a source), “Once an attacker has broken into your computer [and obtained root privileges], it is no longer your computer.” So in principle, there is nothing that 1Password can do to protect you if your computer is compromised.

I also followed that up by saying that in practice there are some things that we can do to make things harder for the attacker. But we have to be choosy. Because the attacker who has compromised your computer can always win, we need to pick our fights in such a way in which a small effort on our part causes a larger effort on the attacker.

As a consequence, we've attempted to focus our efforts on reducing the amount of time that a Master Password or master keys reside in memory. This is because it is plausible that an attacker may have only temporary read access to the system memory instead of full control. The DMA (Direct Memory Access) attacks are such an example.

So we do try to reduce the amount of time that secrets are in memory. We are not entirely where we want to be on this front, but it is an ongoing process of improvement. But you should always assume that the master keys are in memory when 1Password is unlocked. That is pretty much the definition of "unlocked".

Preventing DMA attacks

As I mentioned DMA attacks, let me quote from the Inception project, an open source tool for running the DMA attack:

Inception is a physical memory manipulation and hacking tool exploiting PCI-based DMA. The tool can attack over FireWire, Thunderbolt, ExpressCard, PC Card and any other PCI/PCIe interfaces.

The somewhat good news is that it is possible to configure modern systems to resist this attack, but it does mean some tinkering. Again, from the Inception page:

To stay safe and protect against FireWire DMA attacks, here’s a couple of suggestions:

Windows

• Block the SBP-2 driver
• Remove FireWire drivers from your system if you don’t need to use FireWire

OS X

• Don’t panic – if you are using FileVault2 and OS X Lion (10.7.2) and higher, the OS will automatically turn off DMA when locked – you’re still vulnerable to attacks when unlocked, though
• Set a firmware password

Linux

• Disable DMA or remove the 1394 drivers (see the ‘Mitigation: Linux’ section)

All of the above will impact FireWire in one way or the other. Unfortunately, this is a FireWire design problem, not an OS problem, and would have to be fixed in the SBP-2 protocol itself.

owolf

Thank you for the responses. I already finished my thesis.
The main thing about this questions was to determine which security mechanisms are currently common.
I will use the information in a future version of my thesis.

But i am sure this information will help people with similiar questions and interest in this information.

MikeT

Hi,

On behalf of the team here, you're welcome. Congratulations on finishing your thesis, we'd love to read it if it will be published for the public.