veracrypt / VeraCrypt

Disk encryption with strong security based on TrueCrypt
https://www.veracrypt.fr
Other
6.79k stars 939 forks source link

Elcomsoft claims to have broken the encrypted masterkey in RAM #797

Open JsBergbau opened 3 years ago

JsBergbau commented 3 years ago

https://www.elcomsoft.com/news/787.html

Just wanted to inform that latest version of Elcomsoft claims to have broken the encrypted masterkey in RAM. However as far as I understand the article you need to install the software on the victim PC and you also need admin rights to do so. The tell you need their software to do a RAM dump, other software won't work. Why that? But even without admin rights you can access the encrypted data because volume is mounted. So what is new about this?

So can anyone tell more about this pressrelease? Or is this just marketing stuff?

alt3r-3go commented 3 years ago

This is not new - and BTW they clearly admit (to their credit, as such companies naturally tend to overstate their capabilities and achievements) that the key encryption feature made it harder to extract the keys from memory. This feature was never meant to be an absolute protection, rather a "defense in depth" one that makes the attacker jump over more hoops to get the key. There are more triggers that delete the key upon certain system events (power, device connection) + the master key encryption key depends on a relatively big chunk of the RAM in assumption that cold boot attacks would have harder time preserving in exactly. For the cases when the endpoint (the OS or HW itself) is compromised and the dump is "bit-perfect", there's not much that can be done without resorting to much more complicated solutions like TEEs or some such.

alt3r-3go commented 3 years ago

And just to add to the above - here's a blog post by Elcomsoft going into much more details on this: https://blog.elcomsoft.com/2021/06/breaking-veracrypt-obtaining-and-extracting-on-the-fly-encryption-keys/.

Again - kudos to Elcomsoft team for keeping it objective and referring to Mounir's post about the feature's threat model and goals.

idrassi commented 3 years ago

Thank you @alt3r-3go for sharing Elcomsoft blog post.

I have posted a quick comment on their Press Release on Sourceforge, here is a quote:

The title ca be a little bit misleading for non-technical readers since VeraCrypt as a whole is not broken (offline encryption is still safe) and it is the RAM encryption feature that protects against RAM extraction attacks that is the subject of this announcement.

Anyway, after resisting 20 months, it seems that the cat and mouse game must continue. As I indicated in previous posts on this forums, RAM encryption security can be enhanced by using special CPU registers to hold part of the encryption key since these registers cannot be extracted. I have done a PoC for this technique some time ago but in light of this announcement I will look into it again in the coming weeks to build a stable v2 enhancement of RAM encryption.

Stay tuned...

JsBergbau commented 3 years ago

So when reading the blogpost it looks like only key extraction from RAM is supported if encryption of key in RAM is not enabled. So with enabled encrypyted storage of key in RAM it will fail.

The blogpost claims to have the only software to extract masterkey of veracrypt in RAM and to do so you must use this software, requiring admin privileges. On the other way round this means that even without encrypted key storage in RAM you can't extract the masterkey with commercial available software of a RAM dump created with a cold boot attack. So if so probably only intelligence agencies have the software to do this, if so.

Also when having admin privileges on the target system: All bets are off. You could also just copy the content of the mounted volume to another drive controlled by the attacker.

mrx23dot commented 2 years ago

dump is "bit-perfect", there's not much that can be done without resorting to much more complicated solutions like TEEs or some such.

What about hashing the password to a big ~1MB (deterministic) variable length byte array, with random value&length pre-post byte fillers.

It would be a lot harder to recover 1MB correct data with cold-boot attack, and figuring out start offset and length.

block_cipher_key_withFillers = [pre random fillers | 700KB..1400KB password hash | post random fillers ]

(not sure how it's currently done, but hope it's not clear text)