8 ms·

TrueCrypt Master Key Extraction And Volume Identification

143 points by lelf 13y ago

randywaterhouse 13y ago
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 13y ago
  One important thing this analysis points out: using a truecrypt volume (ie: a USB stick) on a non-truecrypt system is dangerous.
  - randywaterhouse 13y ago
    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.
mrfusion 13y ago
So not safe?
- eponeponepon 13y ago
  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 13y ago
    Until brain scanners become a thing. Then we can all get potentially charged for thought crimes.
- brohee 13y ago
  A lot less secure if not using full disk encryption.
Xymak1y 13y ago
What does this mean for me? I have all my interal + external hard drives encrypted as well as my system drive.
- shawnz 13y ago
  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.
  - Xymak1y 13y ago
    Thank you.
  - mrfusion 13y ago
    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?
    - shawnz 13y ago
      > How would you treat your RAM contents as precious? For one, don't let anyone get physical access to the computer while it is running and the volume is mounted (even if the screen is locked). This may even apply for several minutes after the machine is turned off: https://freedom-to-tinker.com/blog/felten/new-research-result-cold-boot-attacks-disk-encryption/ https://freedom-to-tinker.com/blog/felten/new-research-resul... > Can other unrelated processes access the key from RAM? Processes running as the root user can.
      - MichaelGG 13y ago
        >Processes running as the root user can. Unless you're using a trusted computing environment, right? In which case, if you trust the processor and startup environment, the kernel can be assured to run safely and prevent such attacks. Correct?
gesman 13y ago
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 :)
- vezzy-fnord 13y ago
  That would be steganography then, which is distinct.
- deeringc 13y ago
  The flip side of this is that it becomes impossible for someone to prove that they haven't got an encrypted volume stored somewhere. It will be interesting to see in which way the courts go with this.
  - maxerickson 13y ago
    That's always been impossible.
    - alexkus 13y ago
      Not always (as long as you're talking about something they are in possession of, you're right if you mean you can't prove that you don't have some flash drive hidden somewhere but, then again, it need not be encrypted if they don't have access to it). To start simply, it's certainly possible to prove that a disk installed with a base install of an OS (and then never touched) contains no encrypted volumes if all of the remaining blocks are empty. Every file can be compared to a known good copy and if there's no other data anywhere on the disk then there can't be anything hidden on it. From there it's a case of proving that each bit of extra data on this disk relates to a file available under the OS or a fragment of such a file (now deleted). This gets progressively harder the more the disk has been used. It impossible to deny this when you have a GB+ sized area of unpartitioned data (or unmounted partition) containing seemingly random noise. Or a similar GB+ sized file that you cannot demonstrate to be something benign by unpacking/decrypting/etc. "It's a file of random noise I generated" is going to set off the alarm bells.
revelation 13y ago
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
jtth 13y ago
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?
deleted 13y ago
[deleted]
alister 13y ago
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 13y ago
  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 13y ago
    > 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.
  - nitrogen 13y ago
    How much hand holding do we need to do, here? I don't know who "we" would be in this case, but in general, I'd like to see enough hand holding that everybody can use encryption safely and confidently without having to be cpercival or tptacek.
- imhlv2 13y ago
  Acknowledged - I added a few words about this to the end of the post.
ChrisAntaki 13y ago
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..
- edwardy20 13y ago
  It seems like that would be extremely easy to brute force.
- attrc 13y ago
  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.
cbr 13y ago
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?
- attrc 13y ago
  I hope linking to reddit doesn't get me banned, but this question was asked there and explained nicely: http://www.reddit.com/r/netsec/comments/1va904/truecrypt_master_key_extraction_and_volume/ceqcr99 http://www.reddit.com/r/netsec/comments/1va904/truecrypt_mas...
  - MichaelGG 13y ago
    So it's not the actually the key that's easily located, but the key schedule from which you can get the key out easily?
    - attrc 13y ago
      Yes for projects like aeskeyfind For Volatility we use the TC data structures in memory to lead us to the key (the same ones TC uses to perform reads/writes)
- sweis 13y ago
  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.
  - dobbsbob 13y ago
sgloutnikov 13y ago
Are there any 'better' (knowing it's all relative) alternatives for what TrueCrypt provides?
- ye 13y ago
  Nothing remotely as peer-reviewed and time-tested and open-source.
  - jessaustin 13y ago
    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".
kiwihuck 13y ago
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 13y ago
  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.
crazytony 13y ago
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 13y ago
  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.
lisnake 13y ago
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?

143 points by lelf 13y ago

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 13y ago
One important thing this analysis points out: using a truecrypt volume (ie: a USB stick) on a non-truecrypt system is dangerous.
- randywaterhouse 13y ago
  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.

mrfusion 13y ago

So not safe?

eponeponepon 13y ago
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 13y ago
  Until brain scanners become a thing. Then we can all get potentially charged for thought crimes.
brohee 13y ago
A lot less secure if not using full disk encryption.

Xymak1y 13y ago

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

shawnz 13y ago
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.
- Xymak1y 13y ago
  Thank you.
- mrfusion 13y ago
  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?
  - shawnz 13y ago
    > How would you treat your RAM contents as precious? For one, don't let anyone get physical access to the computer while it is running and the volume is mounted (even if the screen is locked). This may even apply for several minutes after the machine is turned off: https://freedom-to-tinker.com/blog/felten/new-research-result-cold-boot-attacks-disk-encryption/ https://freedom-to-tinker.com/blog/felten/new-research-resul... > Can other unrelated processes access the key from RAM? Processes running as the root user can.
    - MichaelGG 13y ago
      >Processes running as the root user can. Unless you're using a trusted computing environment, right? In which case, if you trust the processor and startup environment, the kernel can be assured to run safely and prevent such attacks. Correct?

gesman 13y ago

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 :)

vezzy-fnord 13y ago
That would be steganography then, which is distinct.
deeringc 13y ago
The flip side of this is that it becomes impossible for someone to prove that they haven't got an encrypted volume stored somewhere. It will be interesting to see in which way the courts go with this.
- maxerickson 13y ago
  That's always been impossible.
  - alexkus 13y ago
    Not always (as long as you're talking about something they are in possession of, you're right if you mean you can't prove that you don't have some flash drive hidden somewhere but, then again, it need not be encrypted if they don't have access to it). To start simply, it's certainly possible to prove that a disk installed with a base install of an OS (and then never touched) contains no encrypted volumes if all of the remaining blocks are empty. Every file can be compared to a known good copy and if there's no other data anywhere on the disk then there can't be anything hidden on it. From there it's a case of proving that each bit of extra data on this disk relates to a file available under the OS or a fragment of such a file (now deleted). This gets progressively harder the more the disk has been used. It impossible to deny this when you have a GB+ sized area of unpartitioned data (or unmounted partition) containing seemingly random noise. Or a similar GB+ sized file that you cannot demonstrate to be something benign by unpacking/decrypting/etc. "It's a file of random noise I generated" is going to set off the alarm bells.

revelation 13y ago

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

jtth 13y ago

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?

deleted 13y ago

[deleted]

alister 13y ago

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 13y ago
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 13y ago
  > 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.
- nitrogen 13y ago
  How much hand holding do we need to do, here? I don't know who "we" would be in this case, but in general, I'd like to see enough hand holding that everybody can use encryption safely and confidently without having to be cpercival or tptacek.
imhlv2 13y ago
Acknowledged - I added a few words about this to the end of the post.

ChrisAntaki 13y ago

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..

edwardy20 13y ago
It seems like that would be extremely easy to brute force.
attrc 13y ago
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.

cbr 13y ago

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?

attrc 13y ago
I hope linking to reddit doesn't get me banned, but this question was asked there and explained nicely: http://www.reddit.com/r/netsec/comments/1va904/truecrypt_master_key_extraction_and_volume/ceqcr99 http://www.reddit.com/r/netsec/comments/1va904/truecrypt_mas...
- MichaelGG 13y ago
  So it's not the actually the key that's easily located, but the key schedule from which you can get the key out easily?
  - attrc 13y ago
    Yes for projects like aeskeyfind For Volatility we use the TC data structures in memory to lead us to the key (the same ones TC uses to perform reads/writes)
sweis 13y ago
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.
- dobbsbob 13y ago

sgloutnikov 13y ago

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

ye 13y ago
Nothing remotely as peer-reviewed and time-tested and open-source.
- jessaustin 13y ago
  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".

kiwihuck 13y ago

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 13y ago
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.

crazytony 13y ago

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 13y ago
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.

lisnake 13y ago

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?