
TrueCrypt Master Key Extraction And Volume Identification - lelf
http://volatility-labs.blogspot.com/2014/01/truecrypt-master-key-extraction-and.html
======
alister
A naive person googling about TrueCrypt and stumbling on this article (well
written with an authoritative tone) will think that TrueCrypt is completely
cracked, and not bother to use it.

This research is interesting and useful, but do we really want to scare off
people from using TrueCrypt?

Couldn't you add a paragraph at the top or to the side that says, for example:

"If TrueCrypt is used in the intended way, i.e., you finish your work with
TrueCrypt, dismount the TrueCrypt volume, and then shut down your computer,
then the data protected by TrueCrypt is secure if your computer is lost,
stolen, or copied at that point."

I understand your intended audience (I'm one of them). But TrueCrypt is the
best protection we've got (in terms of price (free), quality, license terms,
multi-platform support, algorithm choice, etc.). I presume the author likes it
and uses it himself too.

We want more people to use it, right? So let's at least make it clear that it
isn't cracked or broken when used in the intended manner.

~~~
arbitrage
We want more people to use it intelligently. If they're not capable of
understanding the implications of this research, are they really going to be
able to use this software effectively? How much hand holding do we need to do,
here?

~~~
spitfire
> How much hand holding do we need to do, here?

A lot more than is currently the standard.

Security is a horribly complex subject, and the people that need it most often
don't have the time or knowledge to judge tools and sort out implementation
details.

------
revelation
In this blog post, forensic experts realize TrueCrypt uses headers.

But theres still a valuable lesson: a half-encrypted system is a not encrypted
system, and it will leak information. Theres a paper on this from 2008 I
think, before TrueCrypt implemented full operating system encryption:

[https://www.schneier.com/paper-truecrypt-
dfs.html](https://www.schneier.com/paper-truecrypt-dfs.html)

------
gesman
The new era of encryption will be marked not by making existing encryption
solutions more secure, but by concealing the very act of existence of
encrypted data.

"Here's my data but you cannot read it" \- does not runs so well with courts,
high stakes competitors and deep pocketed enemies.

Once it is known "what to crack" the "how to" solution will be found. "Rubber
hose cryptography" is one of these :)

If you're not possessing anything to crack (or so "they" think), you're safe
:)

~~~
ot
Interestingly, this is something Julian Assange worked on several year before
starting Wikileaks:

    
    
        Starting around 1997, he co-invented the Rubberhose deniable encryption
        system, a cryptographic concept made into a software package for the Linux
        operating system designed to provide plausible deniability against
        rubber-hose cryptanalysis;[68] he originally intended the system to be used
        "as a tool for human rights workers who needed to protect sensitive data in
        the field."
    

[http://en.wikipedia.org/wiki/Julian_Assange#Computer_program...](http://en.wikipedia.org/wiki/Julian_Assange#Computer_programming_and_other_employment)

~~~
pessimizer
[https://web.archive.org/web/20110709154812/http://iq.org/~pr...](https://web.archive.org/web/20110709154812/http://iq.org/~proff/rubberhose.org/)

------
randywaterhouse
Interesting writeup and cool that Mr. Ligh has provided these plugins / tools.
On the whole though, doesn't appear to contain much novel information.

Of course, partition-only encryption has weaknesses in that the OS may store
data in another partition (i.e. you've encrypted the "D:" drive but Windows
just dumps a cached file to "C:", let alone the whole pagefile challenge). So
you need to trust your OS to not write the masterkey to disk, which is widely
acknowledged. I personally run with no page file, so memory ought not to be
written to disk by the OS itself (barring a malicious adversary), although
this solution isn't the best for someone on 1GB RAM.

Full-disk encryption would block this attack, i.e. encrypted swap on Linux
(crypttab makes this quite easy) or system-drive on Truecrypt. Even if it's
dumped to disk, you can't get it, again barring online access to the system.
Online access this is all null and void regardless as they could just issue
commands to dump memory to disk no matter what you've done!

~~~
mmastrac
One important thing this analysis points out: using a truecrypt volume (ie: a
USB stick) on a non-truecrypt system is dangerous.

~~~
randywaterhouse
Right.

This would emphasize the need to always be cautious in your use of
cryptosystems, since you cannot simply claim "oh my data is Truecrypt'd". That
will not save you from everything by itself. But if you look into the
documentation, Truecrypt itself warns you about using it, and the threat model
is very careful in defining what steps you need to take to adequately protect
your data with Truecrypt.

It's one of those things where for most people, just a file-volume (the
simplest kind where it's just a file that can be mounted as a block device),
will do fine. The write-to-disk wouldn't happen very often, and to lose your
data to a thief would require both the unlikely "OS dumped the memory to disk"
(meaning the OS doesn't respect the flags TC puts on that memory), AND on top
of that "a thief stole your laptop/desktop/external". If your adversary is
organized crime, a law enforcement agency, or some other state-like actor with
heavy-duty resources and specifically wants y-o-u... Then you'll need to be
very careful and use a full disk encryption solution, or rather just not use a
computer.

Know your tools. Know your adversary. Sleep a little easier knowing both. Or
turn paranoid.

------
cbr

        An advantage you gain right off the bat is that patterns
        in AES keys can be distinguished from other seemingly
        random blocks of data. This is how tools like aeskeyfind
        and bulk_extractor locate the keys in memory dumps, packet
        captures, etc. In most cases, extracting the keys from RAM
        is as easy as this:
    
        $ ./aeskeyfind Win8SP0x86.raw
    

Shouldn't it be possible to store an AES key in a way that's indistinguishable
from random data?

~~~
sweis
At PrivateCore, we keep key material (and the entire Linux stack) pinned in
the CPU cache, then encrypt main memory. This would thwart physical memory
extraction attacks, like cold booting, Fireware, Thunderbolt, NV-DIMMs, bus
analyzers, malicious RAM, etc.

Note, that doesn't help if someone compromises the software stack and extracts
memory contents logically. A compromised kernel running in cache can just
decrypt memory contents.

~~~
codys
I was not aware pinning memory in the CPU cache was even possible. Is this
done via some Linux interface? Or directly by using some hardware feature of
the CPU?

In any case, it sounds like a very interesting way of maintaining greater
protection for secrets.

------
crazytony
I thought that this issue was already well known? Paging of virtual memory
causes keys to be written to disk...

But this article. Wow: "This is a risk that suspects have to live with, and
one that law enforcement and government investigators can capitalize on"

I love it. Only criminals use TC so let's call all TC users 'suspects'.

What about people who have portable devices and want to store sensitive
financial or medical information? What about people who want to backup this
information into a cloud?

~~~
unfamiliar
Its a forensic science post about how law enforcement can compromise TC. I'd
be very worried if the people they were targeting weren't suspects.

------
jtth
How does secure virtual memory work with this? If data in ram, or at least is
encrypted when written to disk, wouldn't that stop this? Do I know what I'm
talking about?

------
Xymak1y
What does this mean for me? I have all my interal + external hard drives
encrypted as well as my system drive.

~~~
shawnz
This article is just an analysis of one of the inherent and well-documented
weaknesses in truecrypt: the fact that the encryption key must stay in RAM the
entire time you are using an encrypted volume. So, as has always been the
case, treat the contents of your RAM as precious when a truecrypt volume is
mounted.

~~~
mrfusion
How would you treat your RAM contents as precious? Just making sure you're on
a pristine machine, and nothing else is running? Can other unrelated processes
access the key from RAM?

~~~
gambiting
Well, in theory, let's say you've got a laptop encrypted with Truecrypt. You
put it in sleep mode instead of switching it completely off or
hibernating,because you are just nipping out for a coffee. An attacker could
then steal it, lower its temperature(let's say they put it in a freezer for a
while), and then extract - literally take out - the RAM from that machine and
plug it into a specially prepared station which would then be used to extract
the contents of that memory. In low temperatures, RAM data retention is
measured in minutes, so all data you had in your system would be preserved,
including the encryption key.

Unlikely? Quite, unless someone like NSA or FBI want your data. Possible? Yes,
with the right resources.

~~~
dobbsbob
Cold boot attacks don't work on DDR3

~~~
sigterm
Why? Do you have any reference?

~~~
nickles
Here's a paper on the subject
[http://www1.cs.fau.de/filepool/projects/coldboot/fares_coldb...](http://www1.cs.fau.de/filepool/projects/coldboot/fares_coldboot.pdf)

~~~
sigterm
Note the comment at the end of the paper. The authors had not been able to do
it successfully with their relatively simple methodology. Sure it is harder
than DDR2 but this doesn't mean it is impossible. As pointed out by the
authors, the failure can simply be due to the memory controller implementation
(or DDR3 protocol itself) on their test setup. If this is the case, then all
it takes is a custom memory controller that is optimized for this type of
extraction.

------
kiwihuck
Forgive a fool. But are the volatility plugins used (truecryptmaster and
truecryptsummary) only provided to students of the official volatility
training or is it released somewhere? Can't find it on their Google code page.

~~~
attrc
right now we are only using them in the class, but in the next Volatility
release (2.4) they will be in SVN like all our other ones.

------
ChrisAntaki
Would it help to store a long string of data in memory, say 10mb. Then place
the key somewhere in the middle of it? The placement could be based on the
password. Just an idea..

~~~
attrc
It would not help. Volatility is not doing any searching, instead it is
reading TC's data structures in memory to find the key. Basically replicating
TC's algos offline.

------
lisnake
I wonder, wouldn't it be useful to hide keys to encrypted container in some
other type of memory, say videocard memory or processor caches?

------
sgloutnikov
Are there any 'better' (knowing it's all relative) alternatives for what
TrueCrypt provides?

~~~
ye
Nothing remotely as peer-reviewed and time-tested and open-source.

~~~
jessaustin
[http://istruecryptauditedyet.com/](http://istruecryptauditedyet.com/)

This suggests that e.g. dm-crypt is definitely more "open-source", and may in
fact be better audited. I guess TC is still more "time-tested".

------
mrfusion
So not safe?

~~~
eponeponepon
Nothing's 100% safe - if data exists and can be read by its owner, de facto it
_can_ be read by someone else. The only "safe" data is that which never leaves
your brain.

~~~
izzydata
Until brain scanners become a thing. Then we can all get potentially charged
for thought crimes.

