If the encrypted drive is mounted at any time while the computer is running, it seems that currently few if any utilities are able to wipe the key material from RAM when it is unmounted. This appears to mean that if the computer is infected with state-sponsored malware after the drive has been unmounted but before the computer is rebooted, a sophisticated remote attacker could learn enough information to later mount the encrypted drive if he either comes into physical possession of it, or even if he remotely intrudes into the target computer.

Consider a scenario in which a whistleblower with knowledge of illegal activities in some government organization or corporation does this:

  • mount an encrypted drive while Tails is disconnected from internet
  • read a file into RAM
  • unmount the drive
  • connect to internet
  • use Tor browser to upload the file to a whistleblower site

Unfortunately, it seems possible that in this scenario the encryption keys for the encrypted drive could still reside in RAM, and if the would-be-whistleblower is subjected to a MITM attack (possibly using a stolen or improperly issued certificate) it seems that at least one widely deployed state-sponsored-malware can steal the key information from the RAM in a running computer. See

  https://tails.boum.org/forum/State-sponsored_malware_can_inventory_RAM/

Someone mentioned in another thread that he/she uses Tails but keeps it running continuously. This would seem to risk a similar danger.

Comment by Anonymous Wed 01 May 2013 08:06:52 PM CEST
What about running sdmem after mounting an encrypted drive while not connected to the internet. Does it clear the pasphrase from RAM? Is this way safe?
Comment by Anonymous Thu 02 May 2013 11:00:14 PM CEST

I don't know. I think this question would require an audit by someone like Jacob A.

In any case, clearly memory wiping should be built into cryptological applications. Due the critical nature of such software, improvements tend to happen slowly because it is so important not to break something else with a new feature.

Comment by Anonymous Sat 04 May 2013 10:24:38 AM CEST

Does it clear the pasphrase from RAM? Is this way safe?

The tools developed for the cold boot attack should be enough to answer this question, when using a supported encryption setup.

Comment by Tails Sat 04 May 2013 01:55:39 PM CEST

On that topic, what do you think about the suggestion that Twofish with 256 bit key may offer some advantages over Rijndael with 256 bit key (AES-256)?

  • Rijndael has an algebraic structure which suggests a possibly fruitful line of reseach into novel attacks based on algebraic geometry; Twofish has a conventional Feistel cipher structure (with S-boxes incorporating key material so unpredictable in advance by the attacker)
  • Twofish is intrinsically more resistant to cold boot attack than Rijndael even if attacker manages to prevent Tails user from properly shutting down Tails using the panic button (e.g. in the scenario in which secret police burst in upon a political dissident and capture a computer running Tails before the victim has a chance to react)
  • Twofish is slightly faster than Rijndael for 256 bit keys

Just to be clear: I agree that from what is known about real-world attacks on almost-whole-disk encryption, it is far more important to ensure that key material is carefully wiped from RAM, assuming a Tails user is able to properly shut down Tails.

Comment by Anonymous Sat 04 May 2013 05:49:52 PM CEST

Re Comment 6:

If you're not running any services that are exposed to the fucking internet(remember there's iptables and your router in between you and them), and they can't physically plant a trojan on your system somehow (ie within your tails cd/usb/iso or in a virus or an installed package)

Just wanted to point out that the Tails threat model should incorporate the expectation that adversaries (often repressive governments which have bought a cyberintrusion-as-a-service package from amoral cyberwar/cyberspy companies like Gamma International) are trying to plant sophisticated malware, usually by means incorporating these features:

  • forcing or tricking a genuine certificate authority into issuing the attacker a legitimate but improperly issued certificate which allows the attacker to "game the system" to masquerade as mozilla.org
  • disguising malware as a legitimate upgrade (perhaps to an add-on such as Noscript)

Please note that this is not a merely theoretical possibility as this has been documented in numerous recent attacks on human rights activists and political dissidents worldwide.

State-sponsored malware may be the most important threat faced by many regular users of Tails

See

 https://tails.boum.org/forum/State-sponsored_malware_can_inventory_RAM/
Comment by Anonymous Sun 05 May 2013 05:41:50 PM CEST

disguising malware as a legitimate upgrade (perhaps to an add-on such as Noscript)

Which leads to the question: Why is "Update Add-ons Automatically" checked?!

Comment by Anonymous Mon 06 May 2013 08:40:40 AM CEST
@16: Sorry, I got confused w/ TBB.
Comment by Anonymous Mon 06 May 2013 09:01:02 AM CEST

Just to prevent any further confusion:

Tails and TBB do some things slightly differently, and in my opinon Tails does a better (more conservative) configuration of the modified browser. In particular, the current TBB does check the automatic updates box, but the current Tails does not, by default.

Comment by Anonymous Wed 08 May 2013 09:35:06 PM CEST