Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TrueCrypt Master Key Extraction And Volume Identification

volatility-labs.blogspot.com

Post reply on HN
Print view View original

51–60 of 75 posts

Re: TrueCrypt Master Key Extraction And Volume Identification

#51

Post by MichaelGG »

attrc wrote: post #49
cbr wrote: post #40

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…

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

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?

Re: TrueCrypt Master Key Extraction And Volume Identification

#52

Post by MichaelGG »

shawnz wrote: post #23
mrfusion wrote: post #19

Earlier quoted context omitted.

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?

> 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-resul... > Can other unrelated processes access the key from RAM? Processes running as the root use…

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

Re: TrueCrypt Master Key Extraction And Volume Identification

#53

Post by sweis »

cbr wrote: post #40

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…

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.

Re: TrueCrypt Master Key Extraction And Volume Identification

#54

Post by attrc »

MichaelGG wrote: post #51
attrc wrote: post #49

Earlier quoted context omitted.

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

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?

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)

Re: TrueCrypt Master Key Extraction And Volume Identification

#55

Post by lstamour »

imhlv2 wrote: post #38
alister wrote: post #30

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

Acknowledged - I added a few words about this to the end of the post.

Thanks for the edit, I really liked the link to the cold boot abstract. Somehow I keep forgetting physical access in a world of radio-controlled computer implants and thunderbolt/firewire DMA.

The examples really made the article shine. I knew you could dump memory, but seeing identification tools in action is ... too easy! :)

Re: TrueCrypt Master Key Extraction And Volume Identification

#56

Post by reubenmorais »

mrfusion wrote: post #19
shawnz wrote: post #7

Earlier quoted context omitted.

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.

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?

Avoid using Thunderbolt/IEEE 1394/DisplayPort or any interface that has DMA to connect devices to your computer.

Re: TrueCrypt Master Key Extraction And Volume Identification

#58

Post by codys »

sweis wrote: post #53
cbr wrote: post #40

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…

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 m…

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.

Re: TrueCrypt Master Key Extraction And Volume Identification

#59

Post by 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?

Re: TrueCrypt Master Key Extraction And Volume Identification

#60

Post by dobbsbob »

sweis wrote: post #53
cbr wrote: post #40

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…

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 m…

PrivExec does something similar with ephemeral keys http://www.onarlioglu.com/privexec/
Post reply on HN